Server-Side Request Forgery: Making the Server Attack Itself

Server-Side Request Forgery earned its place on the 2021 Top 10 in an unusual way: the security community voted it on. It did not rank highly by raw frequency, but practitioners saw it as a rising, high-impact risk that deserved its own line. SSRF is the vulnerability that lets an attacker make your server send requests on their behalf — turning a machine trusted inside your perimeter into a proxy that reaches places the attacker never could.

SSRF occurs whenever an application fetches a remote resource using a URL it accepts from the user, without validating where that URL points. The feature is common and useful: import an image from a link, call a webhook, fetch a document to preview. The flaw is that the server will fetch whatever URL it is given — including addresses the attacker could never reach directly, because they sit behind the firewall the server lives inside.

Why the internal position is the whole prize

A server usually has network reach a remote attacker does not: internal admin panels, databases, and — the crown jewel in cloud environments — the instance metadata service. On many cloud platforms, a request to a special link-local address returns configuration and, historically, credentials for the instance's role. An SSRF that reaches that endpoint can hand an attacker the keys to the cloud account. The 2019 Capital One breach, in which an SSRF was used to reach a metadata endpoint and retrieve credentials, remains the defining public example of this pattern.

SSRF also comes in a blind variety, where the response is not returned to the attacker but side effects still occur — internal services get poked, ports get scanned by timing, requests get smuggled. Blind SSRF is harder to exploit but no less real, and it evades naive defences that only check whether data comes back.

Preventing SSRF

• Allow-list destinations. Permit outbound fetches only to a known, explicit set of hosts rather than trying to block bad ones. Deny by default.
• Validate and resolve URLs carefully. Reject internal, link-local, and private address ranges, and guard against DNS rebinding and redirect tricks that swap a safe host for an internal one after validation.
• Segment the network. Ensure the fetching service cannot reach sensitive internal systems it has no business calling; treat outbound traffic as something to control, not just inbound.
• Harden cloud metadata. Require the newer, session-based metadata service that resists SSRF, and scope instance roles to least privilege so a leaked credential is worth little.
• Do not reflect raw responses back to the user, and disable unneeded URL schemes such as file:// and gopher://.

SSRF is a reminder that the network position of your servers is itself an asset attackers covet — sometimes more than any single record. The defence depends on knowing exactly what each service is allowed to reach, and enforcing it. That map of who-can-call-what is one more thing you cannot secure until you have discovered it in full.