Server-side request forgery

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

Compliance coverage

Findings from this rule map to the following framework controls:

See the full compliance coverage page for how XploitScan maps every rule to SOC 2, ISO 27001, and OWASP Top 10 controls.