Testing how-tos
How to Prevent SSRF (Server-Side Request Forgery)
SSRF lets an attacker coerce your server into making requests to internal systems and cloud metadata endpoints. Preventing it takes more than a naive URL check - it requires resolution-safe validation and defense in depth. Here is a practical hardening sequence.
Steps
- 1
Avoid user-supplied URLs where possible
If a feature does not need to fetch arbitrary URLs, do not let it. Use fixed endpoints or opaque identifiers mapped server-side.
- 2
Allowlist destinations
Where fetching is required, validate the target against a strict allowlist of hosts and schemes rather than trying to blocklist bad ones.
- 3
Resolve once and pin the IP
Resolve the hostname a single time, reject link-local/loopback/private ranges, then connect to that exact IP. This defeats DNS rebinding, which bypasses first-resolution-only checks.
- 4
Harden the cloud metadata service
Require IMDSv2 with a hop limit of 1 so the instance metadata endpoint cannot be reached through SSRF.
- 5
Use an egress proxy
Route all outbound fetches through a proxy that enforces the allowlist and logs requests, so egress is controlled and auditable.
- 6
Test continuously
Re-test for SSRF on every deploy, including rebinding and redirect-based bypasses, since new fetch features reintroduce the risk.
Key takeaways
- Validate after DNS resolution and pin the IP to stop rebinding.
- IMDSv2 removes the most damaging SSRF payoff.
- Egress allowlisting is the strongest structural control.
FAQ
Does blocking 169.254.169.254 prevent SSRF?
No. Blocklisting one address is easily bypassed via alternate encodings, DNS rebinding, or redirects. Resolution-safe allowlisting plus IMDSv2 is the durable fix.
Related
Impactr finds and proves whether flaws like this are actually reachable in your own web apps and APIs, with a reproducible exploit as evidence.