Potential Server-Side Request Forgery (SSRF)

About A10:2021 — Server-Side Request Forgery

SSRF happens when your server makes an HTTP request to a URL the user controls. The attacker uses your server as a proxy to reach internal services — cloud metadata endpoints (which leak credentials on AWS/GCP), internal APIs, or other infrastructure that isn't internet-exposed.

Impact: On AWS, an SSRF that can reach `169.254.169.254` typically yields IAM credentials for the EC2 instance role. From there, the attacker has whatever permissions that role grants — often a lot. SSRF is also used for internal port scanning and reaching services like Redis or Elasticsearch that shouldn't be exposed.

How to fix it: Allowlist the URLs your server can fetch — never let users supply arbitrary URLs. Block requests to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.169.254). Use IMDSv2 on AWS to require a token for metadata access. Run outbound proxies that enforce destination policy.

Common patterns in this category:

• User-supplied URL passed directly to `fetch()` or `axios.get()`
• URL preview / unfurl features without destination filtering
• Webhook test endpoints that POST to whatever URL you give them
• PDF generators that render arbitrary HTML+CSS with remote resources
• Image proxies that fetch any URL

Framework mapping

Findings from this rule map to the following framework controls. This is an informational mapping, not an audit, certification, or attestation.

See the full compliance coverage page for how every rule maps to OWASP Top 10 and CWE, and which rules also carry informational SOC 2 and ISO 27001 cross-references.