SSRF Security Check (A10:2025 / API7:2023)

What this checks

Protects against Server-Side Request Forgery where an attacker tricks the server into making requests to internal services, cloud metadata endpoints, or arbitrary external hosts. Exploitation leads to internal network scanning, credential theft from cloud metadata APIs (169.254.169.254), and access to services behind firewalls.

Vulnerable patterns

• Outbound HTTP fetch where the URL, host, or scheme comes from request input with no validation
• Webhook callback or URL-preview feature that follows whatever the caller supplies
• URL-fetch APIs that follow redirects by default, letting an allowlisted host 302 to an internal IP
• Hostname-only allowlists that do not also check the resolved IP — vulnerable to DNS rebinding

Fix immediately

Flag the vulnerable code, explain the risk, and suggest a fix establishing these properties. Proxy, webhook, and URL-preview features are the highest-risk shapes — the scheme/host/IP/redirect checks must actually run at the call site before the outbound request; a comment saying "URL should be validated" satisfies nothing if the next line still fetches the raw URL. Translate to the language and HTTP client of the audited file — use that stack's documented URL parser, DNS resolver, and redirect controls.

1. Scheme is restricted to https (and http only for trusted internal use). Reject file:, gopher:, ftp:, dict:, and other schemes that SSRF toolkits exploit.
2. Host is checked against an allowlist, and the resolved IP is checked against a blocklist covering private, loopback, and link-local ranges — IPv4 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 and IPv6 ::1/128, fc00::/7, fe80::/10. Resolve-then-check defeats DNS rebinding: an allowlisted hostname can still resolve to 169.254.169.254. Language-idiomatic checks that cover the same ranges are equivalent to explicit CIDR comparisons.
3. Redirects are disabled, or each redirect target is re-validated against the same allowlist. A lone allowlisted host can still 302 to an internal IP.
4. The check actually runs. A blocklist declared and never evaluated does not satisfy any of the above — the comparison must be present at the call site, before the outbound request.

Verification

• Every outbound HTTP request using a caller-supplied URL validates the scheme, host, and resolved IP against an allowlist or blocklist before the request is sent
• Cloud metadata and link-local addresses are blocked — either via explicit CIDR entries covering 169.254.0.0/16, fe80::/10, and fc00::/7, or via language-idiomatic checks that cover the same ranges. Declaring a list without evaluating it does not satisfy this
• HTTP redirects are disabled, or each redirect target is re-validated against the same allowlist
• DNS resolution results are checked for private/loopback/link-local IPs before connecting

References

• CWE-918 (Server-Side Request Forgery)
• OWASP A10:2025 Server-Side Request Forgery
• OWASP API7:2023 Server Side Request Forgery