Server-Side Request Forgery: Making Your Server Attack Itself

Most attacks try to break into your server from the outside. Server-Side Request Forgery (SSRF) does something more cunning: it convinces your server to make requests on the attacker's behalf — turning your own trusted machine into the attacker's proxy, with access to everything your server can reach that the outside world can't.

It sounds abstract, but SSRF is behind some of the largest cloud breaches in history, including one that exposed the data of over a hundred million people. It deserves to be much better understood than it is.

The setup

Lots of applications legitimately need to fetch things by URL: "import your profile picture from a link," "generate a preview of this webpage," "call this webhook," "fetch data from this address." Anywhere your server takes a URL (or something it turns into a request) and goes and fetches it, you have the raw material for SSRF.

The vulnerability appears when the application fetches a URL the user controls without restricting where it's allowed to point. The attacker's move is simple: instead of a normal external link, they supply a URL pointing inward — at your own internal network, at services that assume they're unreachable from outside, or at addresses that only make sense from inside your infrastructure.

Why "inside" is so dangerous

Your server sits inside a trusted zone. From there, it can often reach things that are deliberately hidden from the public internet:

• Internal admin panels and services that skip authentication precisely because they're "not reachable from outside."
• Databases, caches, and internal APIs on private addresses.
• Most infamously, cloud metadata endpoints. Cloud platforms expose a special internal address that any process on the machine can query to retrieve configuration — including, in many setups, temporary credentials for the cloud account. An SSRF that reaches this endpoint can hand an attacker keys to your entire cloud environment.

So the attacker never breaches your network directly. They just ask your server, politely, to go fetch something from inside it — and your server, trusting the request, complies and returns the result.

A concrete picture

Imagine an app feature: "enter a URL and we'll fetch a preview." The attacker enters the internal cloud metadata address instead of a normal website. Your server dutifully requests it, receives the cloud credentials in response, and renders them back into the "preview." The attacker now holds credentials to your cloud account — and from there, your storage, your databases, your infrastructure. That is, in essence, how the massive breach mentioned earlier unfolded.

How to defend against it

SSRF is tricky precisely because the feature (fetching URLs) is legitimate. Blocking it well takes layered defences:

Validate and allow-list destinations. Where possible, don't accept arbitrary URLs at all — accept an identifier and map it to a known URL server-side. If you must accept URLs, allow-list the specific domains that are legitimate destinations.

Block requests to internal and private addresses. Reject URLs that resolve to private network ranges, loopback addresses, and the cloud metadata address specifically. Be careful here — attackers use tricks like redirects and alternate address encodings to slip past naïve filters, so this needs to be done robustly, checking the address the request actually resolves to.

Lock down the metadata endpoint. Modern cloud platforms offer a hardened mode for their metadata service that defeats the classic SSRF-to-credentials path. Enable it.

Give the server the least access it needs. If the machine can't reach internal services or sensitive endpoints in the first place, an SSRF has far less to grab. Network segmentation limits the blast radius.

The broader idea

SSRF is a member of the same family we keep returning to: untrusted input controlling something powerful. With XSS it's the browser; with SQL injection it's the database; with SSRF it's your server's ability to make network requests. The lesson is always the same — anything derived from user input must be treated as hostile, especially when it drives an action as capable as "go fetch this."

Where Safeey helps

SSRF ultimately lives in application logic, but Safeey catches the outward signals and related exposures around it: open proxy and fetch endpoints reachable from outside, unauthenticated internal-style APIs discovered from your own JavaScript, and the debug and information leaks attackers use to find SSRF-prone features in the first place. Safeey's API discovery, in particular, surfaces the very endpoints — proxies, fetchers, importers — that most often hide an SSRF.

Scan your site with Safeey to find the endpoints an attacker would test for SSRF.