SSRF Defense
No single control eliminates SSRF. Input validation on URLs has known bypass techniques. Network egress filtering stops external communication but not internal pivoting. The metadata service has its own mitigations. A complete defense combines all of these layers, because SSRF targets the intersection of application behavior and network architecture.
URL Validation: Allowlist over Denylist
Denylist approaches block known-bad destinations: private IP ranges, localhost, cloud metadata IPs. They are incomplete because the list of addresses that should be blocked is unbounded. Bypass techniques include:
- Decimal and octal IP representations:
http://2130706433/andhttp://0177.0.0.1/both resolve to 127.0.0.1 in many HTTP clients - IPv6 representations of IPv4 addresses:
http://[::ffff:127.0.0.1]/ - URL shorteners and open redirects that resolve to internal addresses
- DNS rebinding (a hostname initially resolving to a public IP that later changes to a private one)
An allowlist specifies the complete set of hostnames or IP ranges the application is permitted to contact. Everything else is denied. For an image resizing service that only fetches from a CDN, the allowlist contains only that CDN's domain. This is operationally harder than a denylist but closes the bypass space.
Resolving and Re-Validating at Connection Time
Validating a hostname at input time and then connecting later creates a window for DNS rebinding. The fix is to resolve the hostname, validate the resolved IP against the allowlist or private-range denylist, and then connect to that specific IP, not re-resolving the hostname. This requires the HTTP client to accept a pre-resolved IP with the original hostname in the Host header, which is supported in curl and most HTTP libraries but requires explicit configuration.
Scheme Restriction
The HTTP client should be configured to accept only https:// (and http:// where required). All other schemes must be disabled in the HTTP client library, not just filtered at the input validation layer. A filter that rejects gopher:// in the input but uses a curl-based client that supports gopher is bypassable if the filter has any gap.
IMDSv2 Enforcement
On AWS, enforcing IMDSv2 by setting HttpTokens: required on EC2 instances and in account-level defaults blocks SSRF-based metadata credential theft through GET-only HTTP clients. It does not block SSRF exploitation of other internal services. It is necessary but not sufficient.
Network Egress Controls
Outbound traffic from application servers should be restricted to the destinations required for the application to function: external APIs, CDN origins, database hosts. A security group or firewall rule that permits only these specific destinations prevents SSRF from reaching arbitrary internal services or arbitrary external servers. This is the layer that stops blind SSRF from being used for data exfiltration even when the URL validation layer fails.
Running the component that makes outbound requests (image fetcher, webhook sender, PDF renderer) in a separate network segment with no access to the internal network, and with outbound HTTP allowed only to specific external destinations, isolates the SSRF surface from the rest of the infrastructure.