What is Server-Side Request Forgery?

What server-side request forgery is

An application takes a URL, or something that becomes a URL, from a user and fetches it. A webhook tester, a document converter that resolves images, a link preview generator, a health check that pings a customer endpoint: all of them are the same shape. The vulnerability is not that the server makes a request. It is that the attacker decides where the request goes, and the request arrives carrying the server identity rather than the attacker identity.

That identity swap is the whole of the impact. The server sits inside a network the attacker cannot reach, and it usually holds credentials the attacker does not have: an instance metadata endpoint, an internal admin panel with no authentication because it is not exposed, a database HTTP interface, a service mesh sidecar. The attacker does not gain code execution. They gain the network position and the ambient authority of the process making the request.

Blind and non-blind variants

If the response body comes back to you, the vulnerability is easy to demonstrate and easy to triage. Most real instances do not behave that way. The server fetches something and returns a status, a thumbnail, or nothing at all. That is a blind SSRF, and the practical difference is that you have to move from reading responses to observing behaviour: an out-of-band collaborator that records DNS lookups and inbound connections, response timing differences, and error messages that differ between a host that resolved and one that did not.

The distinction matters commercially as well as technically. A blind SSRF with no demonstrated internal reach is the finding most often closed as informational, and the difference between a closed report and a paid one is usually whether the tester was able to show that the request landed somewhere that mattered.

Why the usual filters fail

The common defence is a deny-list of internal address ranges, applied to the hostname in the submitted URL. It fails for a reason that is structural rather than a matter of the list being incomplete: the check happens against a string, and the connection happens against an address the resolver produces later. Anything that changes between those two moments defeats the check. A hostname under the attacker control that resolves to an internal address needs no trick at all, and a resolver that answers differently on the second lookup than on the first defeats a check that resolves once and connects again.

Redirect following is the other reliable bypass. An allow-listed host that returns a 302 to an internal address hands the attacker the destination if the fetching client follows redirects, which almost every HTTP client does by default.

What actually fixes it

• Allow-list destinations rather than deny-listing them. A deny-list of internal ranges is a list of the things you thought of.
• Resolve the hostname yourself, validate the resolved address, and then connect to that address. Validating a string and connecting to a name is the gap every bypass walks through.
• Disable redirect following on the fetching client, or re-validate the destination on every hop.
• Send outbound fetches through a dedicated egress proxy with its own network policy, so the application host is not the thing making the decision.
• Remove ambient credentials from the fetch path. On a cloud instance that means requiring a signed token for metadata access rather than relying on the network boundary.