Introduction
SSRF has quietly become one of the most impactful web vulnerabilities. The Capital One breach in 2019 — 100 million customer records — started with an SSRF vulnerability that allowed the attacker to query the EC2 metadata service and steal IAM role credentials. That single vulnerability class has caused more damage in cloud environments than almost any other.
Why SSRF Is So Dangerous in Cloud Environments
Cloud instance metadata services are reachable at 169.254.169.254 from any process running on the instance. If your application makes HTTP requests based on user input — fetching a URL, importing a file from a URL, generating a thumbnail from a URL — an attacker can point that request at the metadata service and retrieve temporary credentials, instance identity documents, and other sensitive configuration.
AWS IMDSv2 mitigates this by requiring a PUT request with a hop limit of 1 to obtain a session token before the metadata service responds. Enforce IMDSv2 on all your EC2 instances and Lambda functions. But do not stop there — SSRF can target internal services, databases, and other cloud APIs, not just the metadata service.
Beyond Cloud Metadata
Internal port scanning through SSRF reveals services running behind the firewall. Redis, Elasticsearch, Memcached, and internal admin panels are common targets. An attacker who can make your server send HTTP requests to arbitrary internal addresses can map your entire internal network topology.
Blind SSRF — where the attacker does not see the response but can observe timing differences or DNS lookups — is harder to exploit but still dangerous. It allows internal service enumeration and can be combined with other vulnerabilities for full exploitation.
Effective Defenses
Input validation is necessary but insufficient. Validate URLs against an allowlist of permitted domains and schemes. But remember that DNS rebinding can bypass URL validation — a hostname that resolves to a public IP during validation but resolves to 169.254.169.254 when the actual request is made.
The most robust defense is a combination: URL allowlisting, DNS resolution verification (resolve the hostname and check the IP before making the request), network-level controls (a firewall rule that blocks outbound traffic to 169.254.169.254 from your application servers), and IMDSv2 as a last line of defense.
If your application needs to fetch arbitrary URLs (like a link preview feature), run that functionality in an isolated network segment with no access to internal resources or cloud metadata.
