SSRF Vulnerability
An attack that tricks a server into making requests to targets the attacker chooses — often internal systems and cloud metadata endpoints the attacker can't reach directly.
What is SSRF?
Server-Side Request Forgery (SSRF) is an attack that abuses a server’s ability to make outbound network requests, tricking it into fetching a URL the attacker controls. If an application takes a user-supplied URL and has the server fetch it — to grab an image, call a webhook, import a document, render a link preview — an attacker can supply a URL pointing not at the intended external resource but at internal systems the attacker can’t reach directly. The server, sitting inside the trusted network, becomes a confused proxy that makes requests on the attacker’s behalf. SSRF climbed into the OWASP Top 10 as cloud architectures made its impact far worse.
Why it’s so dangerous in the cloud
SSRF’s severity comes from the server’s privileged network position. From inside the perimeter, the server can reach things the internet can’t: internal admin panels, databases, other microservices, and — the notorious one — the cloud metadata endpoint at 169.254.169.254. On cloud platforms, this link-local address serves instance metadata, and in the older (IMDSv1) model it would hand out temporary credentials for the instance’s IAM role to anything that asked. An SSRF that reaches it can exfiltrate those credentials and pivot to the cloud account — this exact chain drove the 2019 Capital One breach, the canonical SSRF case study. Beyond credential theft, SSRF enables internal port scanning, hitting internal-only APIs, and reading local files (file://) or cloud services. The cloud fix that matters: IMDSv2 requires a session token obtained via a PUT request with a hop-limit, which defeats the simple GET-based SSRF that made IMDSv1 so exploitable — enforcing IMDSv2 is a critical mitigation.
Defending against it
SSRF defense centers on not trusting user-supplied URLs and constraining what the server may reach. Validate and allow-list destinations — permit only the specific hosts/domains the feature legitimately needs, rather than blocklisting “bad” ones (blocklists are trivially bypassed with IP encodings, redirects, DNS rebinding, and IPv6 tricks). Block access to internal ranges (private IPs, link-local 169.254.169.254, loopback) at the application and network layers. Restrict schemes to http/https, blocking file://, gopher://, etc. Enforce IMDSv2 and give instance roles least privilege so a stolen credential is limited. Network egress filtering — controlling what the server is even allowed to connect to — provides defense in depth. The recurring mistake is relying on blocklists or naive URL parsing; attackers have a deep bag of tricks (decimal/hex IPs, @-tricks, redirects, DNS rebinding) to slip past them, so allow-listing plus network-level controls is the durable approach.
What people get wrong
- Blocklisting instead of allow-listing — IP encodings, redirects, and DNS rebinding defeat blocklists; permit only known-good destinations.
- Leaving IMDSv1 enabled: the GET-accessible metadata endpoint turns a basic SSRF into cloud-credential theft — enforce IMDSv2.
- Trusting URL validation alone — pair input checks with network egress filtering and least-privilege roles so a successful SSRF hits a wall.
Primary source: OWASP: Server-Side Request Forgery
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.