Server-Side Request Forgery (SSRF, OWASP A10) happens when a web app feature that fetches a URL on the user's behalf (image proxy, webhook, PDF renderer, "import from URL") can be pointed at destinations the attacker cannot reach directly — the internal network or, on cloud hosts, the instance metadata service (link-local 169.254.169.254, which serves IAM credentials with no auth).
classify(ip):
169.254.169.254 → metadata (critical: leaks cloud creds)
10.0.0.0/8, 172.16/12,
192.168.0.0/16 → private (internal network)
127.0.0.0/8, ::1 → loopback
else → public
validate(url, mode):
none → always allow
blocklist → reject if the literal string matches known-bad
patterns ("127.", "169.254", "192.168.", ...)
✗ bypassed by decimal/hex/octal IP encoding —
2130706433 == 127.0.0.1 but contains none of
those substrings
allowlist → reject unless hostname ∈ {approved domains}
✗ checked once, at parse time — a DNS record
that resolves to a *different* IP by connect
time (DNS rebinding), or a 302 redirect to an
internal target, both slip through unnoticed
allowlist +
re-resolve → same allowlist check, PLUS the IP is re-resolved
and re-classified immediately before the socket
opens, on every redirect hop — catches rebinding
and redirect-based bypasses too
- Payload — the URL the "fetch remote resource" feature is asked to retrieve, including two classic bypass techniques: numeric-IP obfuscation and DNS rebinding.
- Server-side defense — which validation layer runs before the outbound socket opens; watch weaker modes leak requests that a stronger one blocks.
- Follow redirects — real HTTP clients follow 3xx by default; an initial check that never re-runs on the final hop is a well-known SSRF bypass.
Real-world mitigation combines an explicit egress allowlist, re-resolving DNS immediately before connecting (not at parse time), disabling redirects on server-initiated fetches, and blocking the cloud metadata address at the network layer regardless of application logic.