Web Application Security · intermediate · ~11 min
Explain SSRF, its cloud-metadata impact, and the allowlist-based fix.
SSRF makes the server fetch an attacker-chosen URL, reaching internal services and especially the cloud metadata endpoint (169.254.169.254 → IAM creds). Fix: allowlist destinations/schemes (deny by default), block internal redirects, and require IMDSv2.
SSRF pivots from a web app into the internal network and, in cloud, into full account compromise via stolen instance credentials — one of the highest-impact modern web bugs. Allowlisting (not blocklisting) is the fix testers must recommend.
Server-initiated fetch. Reaches what the attacker can't. Targets. 169.254.169.254 metadata, internal services, localhost, file://. Blocklist pitfalls. DNS rebinding, redirects, IP-encoding bypasses. Fix. Destination allowlist + scheme limits + IMDSv2.
SSRF tricks the server into making a request to a location the attacker chooses. Because the request originates from the server, it reaches places the attacker can't reach directly.
Any feature that fetches a user-supplied URL is a candidate: "import from URL", webhooks, PDF/image generators, URL previews.
POST /fetch url=https://example.com/logo.png ← intended
POST /fetch url=http://169.254.169.254/latest/meta-data/ ← SSRF
The server obediently fetches the second one.
The classic target is the cloud metadata endpoint http://169.254.169.254/, which on misconfigured instances returns IAM credentials — turning SSRF into cloud account compromise. SSRF also reaches internal services (databases, admin panels) behind the firewall, and http://localhost/file:// resources.
file:, gopher:).SSRF abuses URL-fetching features to make the server reach internal or cloud-metadata resources, often yielding IAM credentials. The robust fix is an allowlist of destinations and schemes, plus hardened cloud metadata access.