SSRF Borrows Your Server's Network Position, and Validating the Hostname Does Not Help

SSRF sounds like a minor input-validation issue. It produced the Capital One breach: more than 100 million records, from a single server-side request that retrieved overprivileged credentials from the cloud metadata service.^[1]

The reason it is that severe is worth stating precisely, because it explains why the obvious defences fail. An attacker on the internet cannot reach your internal services and does not hold your credentials. Your server can and does. SSRF is not really about a URL parameter; it is about borrowing your server's position. Every request it makes on the attacker's behalf is made with your network access and your identity.

Why Blocking Internal Addresses Fails

The intuitive fix is a blocklist: reject anything pointing at localhost, private ranges, or the metadata address. It does not work, and the reason is more interesting than the usual explanation about encoding tricks.

Validating the URL and making the request are two separate DNS resolutions. You resolve the hostname to check it. Later, your HTTP client resolves it again to connect. Nothing guarantees those two lookups return the same answer.

DNS rebinding exploits exactly that. The attacker controls a domain and sets a very short TTL, so it resolves to a permitted address while you are validating and to an internal address when the request actually goes out.^[2] Your check passed. It passed against a value that no longer applies.

And note this defeats allowlistsas well: the attacker's domain resolves to an allowed IP on the first lookup and to their chosen IP on the second.^[2] An allowlist is much better than a blocklist, and it is not sufficient if what you are allowlisting is a name. Why DNS is free to behave this way is a consequence of how resolution and TTLs work, covered in what DNS actually does.

The Fix That Actually Closes It

Resolve once, check the address, request the address.^[2]

Concretely: resolve the hostname to an IP yourself. Validate that IP against your rules. Then make the request to that exact IP rather than handing the hostname back to your HTTP client and letting it resolve again. The window the attack needs disappears, because there is no second lookup to poison.

Two things that still need handling once you have done that:

Redirects. An allowed host can respond with a 302 to anywhere. If your client follows redirects automatically, your careful validation covered only the first hop. Either disable following, or re-validate each hop with the same resolve-then-check discipline.

Default-deny egress. The most robust layer is not in your code at all. If the workload can only reach the handful of destinations it genuinely needs, an SSRF bug has nowhere useful to point.^[3] This is the same argument as enumerating an agent sandbox's egress paths, and it is the same lesson from the OpenAI agent escape, which left through the one outbound path its environment had to trust. Outbound is where these failures live and it is the direction nobody inspects.

IMDSv2 Is the Cheapest Big Win

The reason SSRF became critical rather than merely awkward is the cloud metadata service. An unauthenticated HTTP endpoint, reachable from the instance, that hands out credentials. Any SSRF becomes credential theft.

IMDSv2 changes the shape of that endpoint. A caller must first obtain a session token with a PUT request, then present it on subsequent calls, and a hop limit prevents the request being proxied.^[3]

Both requirements are hard for an SSRF to satisfy. Most SSRF primitives give an attacker a GET to a URL of their choice, not the ability to issue a PUT, capture the response header, and replay it. So enforcing v2, which specifically means disabling v1, breaks most naive metadata attacks outright and is described as the single highest-impact fix available.^[3]

Worth being precise about the wording: enabling v2 while leaving v1 available achieves nothing, because the attacker simply uses v1. The change that matters is turning v1 off.

What I Would Do, In Order

Enforce IMDSv2 everywhere and disable v1. Configuration change, no code, removes the worst outcome. Do this first regardless of whether you think you have an SSRF.

Default-deny egress on anything that fetches URLs. Then allowlist the specific destinations that feature needs.^[3]

Resolve once, validate the IP, request the IP.And handle redirects explicitly rather than inheriting your client's default of following them.

Reduce the credentials the workload holds. Capital One was catastrophic partly because the credentials retrieved were overprivileged.^[1] An SSRF that reaches a scoped role with narrow permissions is an incident; one that reaches an over-broad role is a breach. That is an authorization problem rather than a network one, which is where the OWASP API list keeps pointing.