SSRF: making your server speak on someone else’s behalf

The principle

Many features ask the SERVER to fetch a resource at a URL given by the visitor: downloading an avatar from a link, generating a page preview, validating an incoming webhook.

SSRF (Server-Side Request Forgery) happens when an attacker swaps that URL for an address they could never reach directly themselves, but that the SERVER can reach perfectly well — typically the internal network of the company hosting it.

A concrete example

A “your logo URL” field that downloads the image server-side. Instead of a real image, the attacker supplies the address of the internal metadata service specific to cloud platforms (AWS, GCP, Azure) — an address strictly invisible and unreachable from outside the network.

The server, which IS allowed to reach that address from the inside, connects to it on the attacker’s behalf and potentially hands back full cloud access credentials in its own response.

Why it’s serious

An exploited SSRF grants access to the internal network from the outside, using the server as a trusted relay: internal databases normally unreachable, admin panels restricted to the local network, and on the cloud, credentials that sometimes allow full takeover of the entire infrastructure.

OWASP added it in 2021 as its own dedicated Top 10 category (A10:2021), acknowledging its growing importance as cloud architectures became the norm.

How to protect yourself

Never trust a visitor-supplied URL for an outbound request triggered server-side. Use a strict allowlist of authorised domains and schemes rather than a blocklist, which can always be bypassed one way or another.

Explicitly block private address ranges and the cloud metadata address at the network level, not just the application level. Disable automatic redirects on the outbound request, or fully revalidate them at every hop.

How SauronSec detects it

Several combined signals: cloud metadata signatures present in the response (masked before any display, never exposed as-is in the final report), network errors typical of an internal connection attempt, an abnormal response delay toward a non-routable address that betrays a connection stuck mid-attempt.

For cases entirely invisible in the response, an out-of-band channel (a DNS or HTTP callback to a neutral, controlled collector) confirms the server did issue the requested call, without ever depending on a visible signal in the response itself.