Server-side request forgery (SSRF): the complete guide
Server-side request forgery went from a mid-tier vulnerability to a headline-grabbing one over the last few years, largely because of the cloud. It earned its own dedicated place in the OWASP Top 10 (OWASP documents the class in full on its SSRF page), and it has been the root cause of several of the largest data breaches on record.
This guide explains exactly how SSRF works, why cloud infrastructure makes it so severe, and the layered defences that genuinely stop it.
What is SSRF?
Most web applications make outbound requests as part of normal operation. They fetch an image from a URL you provide, generate a PDF from a link, deliver a webhook, or call a third-party API. In all of these, the server is the one making the network request.
SSRF happens when an attacker can control where that server-side request goes. Instead of the server fetching a legitimate resource, the attacker points it at something else: an internal system, a cloud metadata endpoint, another service on the private network.
The reason this is so powerful comes down to position and trust. The attacker, sitting on the public internet, cannot reach internal systems directly. Firewalls block them. But the server can reach them, because it lives inside the trusted network. By hijacking the destination of the server’s request, the attacker borrows the server’s privileged network position.
A simple example. An application lets you set a profile picture by URL:
POST /api/profile/avatar HTTP/1.1
Host: app.example
Content-Type: application/json
{"image_url": "https://cdn.example/pics/me.png"}The server dutifully fetches that URL and stores the image. But what if the attacker sends this instead?
{"image_url": "http://169.254.169.254/latest/meta-data/"}Now the server is making a request to the cloud metadata service on the attacker’s behalf. If the application returns any of that response, or even behaves differently based on it, the attacker has a foothold into the internal environment.
Why the cloud made SSRF critical
The single biggest reason SSRF became a top-tier vulnerability is the cloud instance metadata service.
Cloud providers give each virtual machine an internal endpoint (classically at the link-local address 169.254.169.254) that returns information about the instance: its configuration, its network, and, in many setups, temporary security credentials for the cloud role the machine is running as.
This is by design and is normally safe: only code running on the instance can reach that address. But SSRF breaks that assumption. If an attacker can make a vulnerable application on that instance request the metadata endpoint, they can potentially retrieve those temporary credentials, then use them to access cloud storage buckets, databases, and anything else the instance’s role is permitted to touch.
This exact pattern (SSRF reaching the metadata service to steal cloud credentials) was a central element of several major breaches, including large incidents affecting financial and technology companies. It’s why cloud providers introduced hardened metadata schemes (such as AWS’s IMDSv2, which requires a session token and blocks naive SSRF), and why locking down that endpoint is now a baseline control.
What an attacker can do with SSRF
The impact of SSRF ranges from information disclosure to full compromise, depending on what the server can reach:
- Steal cloud credentials from the metadata service, leading to broad cloud account access.
- Access internal services: admin panels, databases, message queues, and internal APIs that were “protected” only by not being reachable from the internet.
- Scan the internal network. By observing response times and errors, an attacker can map which internal hosts and ports are alive, using the server as a proxy.
- Reach non-HTTP services. With certain URL schemes, SSRF can interact with services that never expected untrusted input, sometimes escalating toward remote code execution.
- Bypass access controls. Internal endpoints often trust requests coming from inside the network and skip authentication, exactly the trust SSRF exploits.
Because the server frequently sits at a trusted crossroads inside the infrastructure, a single SSRF can unlock a great deal.
In-band vs blind SSRF
SSRF comes in two flavours based on whether the attacker can see the result.
In-band (basic) SSRF returns the response of the forced request to the attacker within the application. If the avatar-fetching feature above displays or leaks the fetched content, the attacker reads internal responses directly. This is the easiest to exploit and confirm.
Blind SSRF makes the server send the request, but the response is never shown to the attacker. It’s harder to exploit but far from harmless. Testers confirm blind SSRF using an out-of-band technique: they point the server at a system they control and watch for the incoming connection. Even without reading responses, blind SSRF can map internal networks by timing, trigger state-changing internal endpoints, and serve as a component in a larger chain.
Where SSRF hides
When testing an application, always within authorised scope, look anywhere the server fetches a URL you influence:
- Webhooks: “send events to this URL” is a direct invitation.
- Import from URL: importing data, documents, or feeds from a supplied link.
- URL preview generators: features that fetch a link to show a title and thumbnail.
- PDF, screenshot, and document generators: these render a supplied URL server-side and are notorious SSRF sinks.
- Image and file fetchers: avatar-by-URL, remote file processing, media proxies.
- Third-party API integrations where you supply the endpoint.
If your input becomes a destination the server visits, test it carefully. For API-heavy applications, pair this with the methodology in the API security testing guide.
How to prevent SSRF: defence in depth
SSRF is stubborn because naive filters are easy to bypass: alternate IP encodings, redirects, DNS rebinding, and unusual URL schemes all work around them. Effective prevention layers several controls.
1. Enforce a strict allowlist
The strongest defence is to not accept arbitrary destinations at all. If your feature only ever needs to reach a handful of known domains, allow exactly those and reject everything else. Allowlisting is far more robust than trying to blocklist every dangerous address, because you don’t have to anticipate every trick. Anything not explicitly approved is denied.
2. Validate the resolved destination, not just the string
Attackers bypass string checks with redirects and DNS rebinding: a hostname that passes validation but resolves to an internal address a moment later. Validate the destination after DNS resolution, verify the resolved IP is in your allowlist, and be wary of following redirects to new hosts without re-validating.
3. Block internal and reserved IP ranges
Reject requests whose resolved address falls in private or reserved ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, loopback 127.0.0.0/8, and, most importantly, the link-local 169.254.0.0/16 range that includes the metadata endpoint. (This site’s own subdomain finder applies exactly this kind of IP guard on any URL it resolves, precisely to avoid becoming an SSRF vector.)
4. Disable unused URL schemes
If your feature only needs http and https, reject everything else. Schemes like file://, gopher://, dict://, and ftp:// are common escalation vectors and are almost never legitimately needed.
5. Harden the cloud metadata service
Enforce the hardened metadata scheme your provider offers, for example require IMDSv2 on AWS so that a simple SSRF can’t read the metadata endpoint. Apply least-privilege to the instance’s cloud role so that even stolen credentials are limited.
6. Segment the network
As a final layer, restrict what the application server is allowed to reach at the network level. If the server has no route to sensitive internal systems in the first place, an SSRF has far less to work with. Defence in depth means assuming one layer will fail and making sure the next one holds.
Key takeaways
- SSRF lets an attacker make a server send requests to destinations they choose, borrowing the server’s trusted internal position.
- The cloud metadata service turned SSRF into a critical vulnerability capable of yielding cloud credentials and major breaches.
- It hides anywhere the server fetches a user-supplied URL: webhooks, importers, PDF generators, image fetchers.
- Prevention is layered: strict allowlisting, validating the resolved destination, blocking internal IP ranges, disabling unused schemes, hardening metadata, and network segmentation.
SSRF rewards attackers who understand networks and defenders who assume their internal systems are reachable. Treat every “fetch this URL for me” feature as a place where that assumption gets tested.
The OWASP SSRF Prevention Cheat Sheet covers allowlisting and network-layer controls in implementation detail, and PortSwigger’s free SSRF labs cover the cloud metadata and filter-bypass cases hands-on. Note that RFC 1918 defines the private address ranges your allowlist has to account for.
Continue learning with the OWASP Top 10 breakdown, test real header and TLS posture with our free security tools, or build these skills directly through hands-on training.
