Server-Side Request Forgery (SSRF) is the vulnerability class that keeps producing critical findings even in 2026. The reason isn’t that developers don’t know about it — it’s that modern applications make HTTP requests from the server in dozens of places, and each one is a new SSRF sink. This module explains why SSRF persists, the surprising number of ways it manifests, and why cloud metadata endpoints made it catastrophic.
Why this happens
Every modern application needs the server to fetch something: webhooks, OAuth callbacks, link previews, PDF rendering, image thumbnails, SAML federation, OpenID JWKS fetches, content mirrors, health checks, avatar imports, RSS feeds. Each feature takes a URL from somewhere and has the server make an HTTP request.
The assumption the developer makes: “the user supplies a URL, the server fetches it, the result goes back to the user.” What the developer doesn’t think about: “the server has different network access than the user does.” The server is inside a VPC, inside a network segment, inside a cloud account. The cloud metadata endpoint at 169.254.169.254 is reachable from the server but not from the user. Internal databases are reachable from the server but not from the user. The server, in other words, is a proxy into places the attacker cannot reach directly.
SSRF gives the attacker that proxy.
How it happens
The classic pattern: endpoint accepts a URL parameter, server fetches it, returns content. Attacker sets URL to internal resource:
- Cloud metadata:
http://169.254.169.254/latest/meta-data/iam/security-credentials/ → temporary cloud credentials. IMDSv1 = instant RCE if server has any IAM role. IMDSv2 (required PUT with token) blocks this unless the attacker can coerce a PUT, which is harder but not impossible.
- Internal services:
http://internal-admin.corp.local/users — admin endpoints meant for internal use, now callable by the attacker via the server as proxy.
- Localhost services:
http://127.0.0.1:9200/_cat/indices — Elasticsearch, Redis, Docker socket, Consul, Kubernetes API, all listening on localhost without external auth.
- file:// or gopher:// schemes:
file:///etc/passwd, gopher://localhost:25/_HELO (SMTP relay). Scheme attacks when input validation only checked for http/https.
- DNS-based bypass: attacker’s domain has an A record pointing to 169.254.169.254. URL validation passes (domain looks external); resolution hits internal.
- Redirect chains: attacker’s server returns 302 to internal URL; many libraries follow redirects by default.
Why we look
Because SSRF frequently escalates to cloud-credential theft, which escalates to cloud-account compromise. Capital One’s 2019 breach — one of the largest in US history — started with SSRF. Indian cloud-native SaaS companies have had similar incidents that don’t make headlines. Every URL parameter in a backend application is a potential SSRF — and the blast radius depends on what’s reachable from inside.
🔐 Intermediate Module · Basic Tier
Continue reading with Basic tier (₹499/month)
You've read 23% of this module. Unlock the remaining deep-dive, quiz, and every other Intermediate module.
99+ modulesAll levels up to this tier
20-question quizzesUnlimited retries with explanations
Completion certificatesShareable on LinkedIn
7 more sections locked below
