We Found an SSRF at a Client — What It Is, and Why It Matters

We found a Server-Side Request Forgery (SSRF) vulnerability at one of our clients. Since it is one of the more misunderstood bug classes, here is the short version of what it is and why it matters.

What is SSRF?

Server-Side Request Forgery is an attack that lets an attacker make the server send an HTTP request to anywhere they choose – from the server itself. That means from inside the internal network, with the server’s own identity and network position.

The danger is not the outbound request on its own. It is where that request can reach: a server sitting behind the firewall can often talk to internal services, admin interfaces, and cloud metadata endpoints that were never meant to be exposed to the outside world. An SSRF turns the application into a proxy into your internal network.

Why it keeps happening

Anywhere an application fetches a URL on the user’s behalf – a webhook, a “preview this link” feature, an image loaded from a remote address, an integration that calls a third party – is a candidate. If the destination is influenced by user input and the outbound request is not constrained, you have the ingredients for SSRF.

What to do about it

• Do not let user input decide, unchecked, where the server sends a request. Validate against an allow-list of destinations, not a block-list.
• Block access to internal ranges and to cloud metadata endpoints from the application’s HTTP client.
• Treat the response carefully too – do not reflect internal responses back to the user.

On its own an SSRF can look academic. In a real assessment it is often the first link in a chain that ends somewhere far more serious.

I first shared a version of this as a LinkedIn post on 2025-09-30. It is republished here, lightly edited, so it is easier to find and reference. — Erez Metula