SSRF (Server-Side Request Forgery)
SSRF tricks a server into making HTTP requests to attacker-chosen destinations, often reaching internal-only systems.
Definition
Server-Side Request Forgery (SSRF) is a class of vulnerability in which an attacker abuses an application's request-making functionality to coerce the server into issuing HTTP or other network requests to destinations the attacker controls. Because the request originates from the server — typically inside a trusted network perimeter — it can reach internal services, cloud metadata endpoints, and other resources that are firewalled off from the public internet.
A typical SSRF surface is any feature where the application fetches a URL the user provided: a webhook delivery, a URL-preview generator, a server-side import-from-URL workflow, a PDF render-from-URL endpoint, a profile-image fetcher. When input validation is incomplete, the attacker substitutes a URL that points at internal infrastructure: `http://127.0.0.1:6379` for a local Redis, `http://169.254.169.254/` for cloud instance metadata, or `file:///etc/passwd` when the underlying HTTP client also accepts non-HTTP schemes.
The bug pattern is reachability, not a memory-corruption issue. A successful SSRF typically does not crash the process; it returns the contents of an internal resource to the attacker, or performs a state-changing action against an internal API that has no separate authentication of its own.
How it works
The application receives a URL from an untrusted source and passes it to a generic HTTP client without restricting the scheme, host, or resolved IP. The attacker submits a URL pointing at an internal endpoint. The HTTP client resolves the hostname, opens a connection from the server, and the response body — possibly including credentials, internal API output, or cloud metadata — is returned to the attacker in the application's response.
A common variant is "blind" SSRF, in which the response body is not exposed to the attacker but a side channel (timing, error messages, log injection, DNS) still leaks information. Cloud metadata services (AWS IMDSv1, GCP metadata, Azure IMDS) are the most-exploited target because a single GET against them historically returned IAM credentials with no authentication.
Impact
Successful SSRF typically leads to credential theft from cloud metadata, internal port scanning, exfiltration of sensitive internal data, and pivoting into deeper post-exploitation. In environments that use SSRF-prone IAM roles, the impact escalates to full account takeover.
Mitigation
Validate the destination both at the URL-parse layer and after DNS resolution. Maintain an allowlist of permitted hosts (not a denylist — DNS rebinding defeats denylists). Reject responses to private IP ranges (RFC 1918, link-local, loopback). Disable redirect-following or follow redirects through the same validation. On AWS, require IMDSv2 (session-token-bound) and set a low metadata hop limit so containers can't see the host's role. OWASP maintains a detailed SSRF prevention cheat sheet.
Examples
- CVE-2021-21972 — VMware vCenter Server SSRF in the vSphere Client.
- CVE-2019-11043 — Capital One breach leveraged AWS metadata SSRF on a misconfigured WAF.