Server-Side Request Forgery
Key Takeaways
- Server-side request forgery (SSRF) tricks your server into making requests an attacker controls, from inside your trusted network.
- Because the request comes from the server, SSRF can reach internal services, private APIs, and cloud metadata endpoints that outsiders cannot.
- Full-read SSRF returns internal responses to the attacker; blind SSRF returns nothing but is still exploitable and easy to overlook.
- The strongest SSRF prevention combines strict destination allowlisting with network segmentation, not blocklists or a WAF alone.
- SSRF is a logic-adjacent flaw that automated scanners frequently miss, because catching it means reasoning about intended behavior.
What Server-Side Request Forgery Is
Server-side request forgery is a web vulnerability that lets an attacker make your server send requests on their behalf. The application is tricked into fetching a URL the attacker controls, so the request originates from inside your infrastructure rather than from the open internet.
That distinction is the whole problem. Your server usually sits behind the firewall, holds credentials, and can reach internal services that outsiders cannot. An SSRF vulnerability turns the server into a confused proxy, a foothold to reach systems that were never meant to be exposed.
The flaw appears anywhere an application takes a user-supplied address and fetches it: webhook configuration, link previews, document importers, PDF renderers, or integrations that pull data from a URL.
How SSRF Attacks Work in Practice
Picture a feature that generates a preview of any link a user submits. The user pastes a URL, the server fetches it, and a thumbnail appears. Legitimate use points that fetch at public websites.
An attacker instead submits an address pointing inward: an internal admin panel, a database on the private network, or a cloud metadata service. The server, unable to tell the difference, dutifully makes the request and may return the response straight back.
From there the attack escalates. The attacker maps the internal network by trying different addresses and watching how the server responds, then probes for services that trust internal traffic and skip authentication. In cloud environments, an SSRF attack against a metadata endpoint can surface temporary credentials that unlock far more than the original application.
Blind SSRF vs Full-Read SSRF: What Each One Means
The two main variants differ in whether the attacker sees the response. Full-read SSRF returns the fetched content directly, so the attacker can read internal pages, pull data from private APIs, and harvest metadata responses. It is the more immediately dangerous form, because it delivers both reach and readback.
Blind SSRF gives no direct response. The server makes the request, but the result never comes back. That sounds harmless, which is exactly why blind SSRF is easy to underestimate.
It is still dangerous. An attacker confirms it by pointing the server at a system they control and watching for the connection. Once confirmed, they can trigger actions on internal services, map the network through timing and error differences, and sometimes chain the flaw into remote code execution, all without seeing a page.
How to Detect and Prevent Server-Side Request Forgery
Effective SSRF prevention starts where the application handles a user-supplied URL. Validate destinations against a strict allowlist of permitted hosts rather than blocklisting bad ones, since blocklists are trivially bypassed with alternate encodings and redirect tricks. Resolve and check the address after following redirects, not just the string the user submitted.
Network design carries equal weight. Segment the environment so servers making outbound requests cannot reach sensitive internal services, and lock down cloud metadata endpoints, a frequent SSRF target. Disable unused URL schemes such as file:// and gopher:// that widen what an attacker can reach.
Detection is harder, because SSRF often produces legitimate-looking outbound traffic and blind variants leave little trace. It is a class of flaw that pattern-matching scanners routinely miss, since finding it means reasoning about what the application is supposed to do. It surfaces reliably in a thorough penetration testing report, and the offensive techniques used to find it are catalogued across common penetration testing frameworks.
FAQ
Yes, and it is one of the most damaging SSRF scenarios. Cloud platforms expose an internal metadata service that returns instance details and, often, temporary credentials. An SSRF vulnerability lets an attacker reach that endpoint from the server and steal those credentials, escalating from a single web flaw to broad cloud account access.
No. Any feature that makes the server issue a request based on user input can be vulnerable, even when the intended target is internal. Webhooks, file imports, PDF generators, and integrations that resolve hostnames all qualify. The common thread is server-controlled requests influenced by user data, not whether the destination is external.
SSRF undermines controls that assume threats come from outside. Because the request originates from a trusted internal server, firewalls and services that grant implicit trust to internal traffic wave it through. Strong network segmentation limits the blast radius, but SSRF specifically exploits the gap between perimeter defenses and flat internal networks.
Not on its own. A web application firewall can catch some obvious payloads, but attackers bypass signature-based rules using alternate IP encodings, DNS rebinding, and open redirects. Treat a WAF as one layer, not a solution. Reliable defense comes from allowlisting destinations and segmenting the network at the application level.