Last updated: April 29, 2026
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.
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.