Server-Side Request Forgery (SSRF) Explained

Server-Side Request Forgery tricks a server into making a network request to a destination the attacker chooses, rather than one the application's own logic intended. The server, not the attacker's own machine, ends up doing the actual reaching.

Why that distinction matters so much

A server typically sits somewhere a normal outside attacker cannot reach directly: inside a private network, with access to internal-only services, or with the ability to query cloud metadata endpoints that hold real credentials. SSRF turns the server itself into a proxy the attacker never needed direct network access to use.

Common places SSRF hides

• A feature that fetches a URL provided by the user: generating a preview image, importing a file from a link, validating a webhook endpoint.
• PDF or document generation features that render user-supplied URLs or HTML.
• Any integration that accepts a callback URL and later makes a request to it.

Why simple blocklists usually fail

A common but weak defense is blocking requests to obviously internal-looking addresses. Attackers routinely bypass this through DNS rebinding, redirect chains that only reveal the real internal destination after the initial check has already passed, or alternate IP address representations that a naive filter does not recognize as equivalent. A redirect an application follows without re-validating each hop is a particularly common way this kind of defense quietly fails.

Better defenses

• Allowlisting specific, known-safe destinations rather than trying to blocklist every dangerous one.
• Validating every redirect hop independently, not just the initial request's destination.
• Network-level segmentation so that even a successful SSRF cannot reach genuinely sensitive internal services.

SSRF is explicitly called out in the OWASP Top 10, and for good reason: it is one of the categories where a seemingly minor feature can expose an organization's entire internal network to an outside attacker.