SSRF (Server-Side Request Forgery) is one of the most dangerous vulnerabilities of the cloud era: instead of attacking the user's browser, the adversary tricks the application itself into making network requests on their behalf. Because the server usually sits inside the trusted network, the attacker gains a foothold to reach internal services, admin panels and, above all, the cloud metadata endpoints that hold credentials. Recognized as its own category in the OWASP Top 10 of 2021, under the code A10:2021, SSRF has gone from a niche case to a central concern of any modern architecture.
What is SSRF (A10:2021)
An application vulnerable to SSRF accepts, directly or indirectly, a URL or destination address supplied by the user and makes a network request to that destination without validating it properly. The name describes the mechanism precisely: just as in CSRF the attacker forges requests coming from the victim's browser, in SSRF they forge requests coming from the server. The difference is decisive, because the server normally operates in a much more privileged network position than any external client.
OWASP included SSRF as a standalone category in the 2021 Top 10 precisely because its incidence grew with the adoption of microservices, APIs that consume other APIs, webhook integrations and functions that fetch remote resources. Formally, the weakness is cataloged as CWE-918: Server-Side Request Forgery (SSRF). It rarely appears alone: it is almost always combined with a permissive cloud configuration and a lack of network segmentation, which amplifies the impact dramatically.
How it works in practice
Consider a common feature: a function that generates the thumbnail of an image from a URL provided by the user. The front end sends something like POST /thumbnail { "url": "https://example.com/photo.png" } and the back end downloads the image to process it. If the server fetches any URL without restriction, the attacker replaces the value with an internal destination:
POST /thumbnail HTTP/1.1
Content-Type: application/json
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }From the server's point of view, it is just another outbound request. But the destination 169.254.169.254 is the cloud instance's metadata address, and the response may contain temporary credentials. Patterns that open the door to SSRF include: data import by URL, PDF generation from remote HTML, webhook verification, image proxies, payment integrations that call callback endpoints and any parser that resolves external references (XML with entities, for example).
It is worth noting that exploitation does not always use the http scheme. Depending on the client library, the attacker can abuse file:// to read local files, gopher:// to forge traffic to services that speak text protocols (such as Redis or SMTP) and dict:// to probe ports. HTTP redirects are also a vector: the initial URL looks harmless but returns a 302 pointing to the internal address.
Attackers also exploit the way each language interprets URLs to bypass naive filters. Addresses can be written in decimal or hexadecimal notation (http://2852039166/ is equivalent to http://169.254.169.254/), with character encoding, with credentials embedded in the user@host format or by exploiting discrepancies between the parser that validates and the parser that actually connects. These bypass techniques explain why approaches based on regular expressions and blocklists almost always fail against a determined adversary — and why robust validation must operate on the already-resolved IP, not on the URL text.
The attacker's preferred targets
Cloud metadata and IAM credential theft
The number-one target is the instance metadata service (IMDS). In all major clouds it responds at the link-local address 169.254.169.254. In AWS, the path /latest/meta-data/iam/security-credentials/<role> returns temporary access keys associated with the instance's IAM profile. In GCP, the same address serves OAuth tokens via /computeMetadata/v1/ (protected by a Metadata-Flavor: Google header). In Azure, the endpoint /metadata/identity/oauth2/token delivers tokens for the managed identity. Once in possession of these credentials, the attacker is no longer limited to the application: they assume the identity of the cloud workload and begin acting with the privileges of that profile. This is why SSRF goes hand in hand with the principle of least privilege, detailed in IAM in cloud.
Internal services and lateral movement
Beyond metadata, the attacker uses the server as a springboard to reach resources that should not be accessible from outside: databases, caches such as Redis and Memcached, message queues, administrative consoles of orchestrators (Kubernetes, Docker), CI/CD panels and internal APIs left unauthenticated because they assumed they were on a closed network. Many of these services implicitly trust any connection coming from inside the network.
Port scanning and mapping
Even without obtaining data directly, SSRF enables port scanning: by varying the host and port in the URL and observing the response time or the error message, the attacker maps which internal services exist and where. It is infrastructure reconnaissance carried out by the victim's own application. From that map, the adversary prioritizes the most valuable targets and chains SSRF with other flaws — an unauthenticated internal API, an exposed cache or an administrative console — turning a seemingly harmless entry point into deep compromise of the environment.
Blind SSRF
The response of the internal request does not always come back to the attacker. In blind SSRF, the application makes the request but does not return the response body to the client. This reduces, but does not eliminate, the risk. The attacker resorts to side channels: measuring differences in response time to infer whether a port is open, provoking distinct errors for different destinations, or using an external collection server (an out-of-band technique) to confirm that the request arrived — for example, by pointing the URL to a domain under their control and watching the DNS or HTTP log. Even blind, SSRF is enough to scan the internal network and, in some cases, to execute actions with a side effect (triggering an endpoint that restarts a service, for example).
Impact: the Capital One case
The most cited example of SSRF is the Capital One breach in 2019. A misconfigured web application firewall allowed an attacker to induce the server to query the AWS metadata endpoint (169.254.169.254) and obtain the temporary credentials of the IAM profile associated with the instance. With those credentials, it was possible to list and read S3 buckets, resulting in the exposure of data from approximately 100 million customers in the United States and about 6 million in Canada. The episode illustrates the typical amplification chain: an isolated SSRF, combined with an overly permissive IAM profile and an old version of the metadata service, turned into one of the largest breaches in the financial sector. The lesson is not just to fix the SSRF, but to break every link in the chain.
Defense in depth
No single measure solves SSRF; effective protection combines controls in the application, in the cloud and on the network. The table below relates each vector or target to the recommended mitigation.
| Vector / Target | Recommended mitigation |
|---|---|
| Arbitrary URL supplied by the user | Strict allowlist of permitted domains and schemes; reject anything not on the list |
| Access to internal and link-local IPs (169.254.0.0/16, 127.0.0.0/8, 10/8, 172.16/12, 192.168/16, ::1) | Block private, loopback and link-local ranges after resolving DNS, before connecting |
| Cloud metadata on AWS | Enforce IMDSv2 (mandatory token via PUT) and reduce the hop limit; consider disabling IMDS where it is not used |
| DNS rebinding (TOCTOU between validation and connection) | Resolve the hostname once, validate the resolved IP and connect to exactly that IP |
| Dangerous schemes (file, gopher, dict, ftp) | Allow only http/https; disable non-essential schemes and protocols in the client library |
| Redirects to internal destinations | Disable automatic redirect following or revalidate each hop against the allowlist |
| Internal services that trust the network origin | Network segmentation and microsegmentation; require authentication even on east-west traffic |
| Blind SSRF and out-of-band exfiltration | Egress firewall restricting outbound destinations; monitor and alert on traffic to 169.254.169.254 |
Validation in the application
The primary defense is an allowlist of destinations: instead of trying to enumerate everything that is dangerous (the denylist approach, fragile by nature), allow only the few legitimate domains and schemes the feature actually needs. Whenever the business logic permits, prefer replacing the free-form URL with an identifier that the back end maps internally to the real destination. When validating a URL, resolve the hostname and check that the resulting IP does not belong to private, loopback or link-local ranges; and connect to the already-validated IP, not to the hostname, to close the DNS rebinding window (in which the same name resolves to a public IP during validation and to an internal IP at connection time).
Cloud hardening
On AWS, migrate to IMDSv2, which requires a token obtained via a PUT request before any metadata read — which breaks most SSRF attacks based on a simple GET. Reduce the response's hop limit to make access from containers harder, and disable IMDS entirely where the workload does not need it. Combine this with least-privilege IAM profiles: if the instance role can only read a specific bucket, the credential theft yields far less. On GCP and Azure, apply the equivalent by restricting the scopes and permissions of the managed identities.
Network and monitoring
Network segmentation limits how far a forged request can reach. An egress firewall that explicitly restricts the application's outbound destinations is one of the most effective controls against blind SSRF and out-of-band exfiltration. A WAF helps block known exploitation patterns, but it should be treated as a complementary layer — never as the only line of defense, precisely because a misconfigured WAF was at the origin of the Capital One case. Finally, monitor and alert on any attempt to send traffic to 169.254.169.254: in legitimate production, that access coming from the application is almost always a sign of compromise.
References
- OWASP — Server-Side Request Forgery Prevention Cheat Sheet
- OWASP Top 10 — A10:2021 Server-Side Request Forgery (SSRF)
- MITRE — CWE-918: Server-Side Request Forgery (SSRF)
- Public analysis of the Capital One breach (2019) and the role of IMDS/IMDSv2
Conclusion
For companies operating in the cloud — from a startup with a handful of employees to an organization with more than 100,000 — SSRF is a risk that cuts across development, architecture and operations. Fixing a single endpoint is not enough: you must combine rigorous input validation, hardening of the metadata service, least-privilege IAM and network segmentation so that an isolated flaw does not turn into a breach of millions of records. Decripte helps your team map where SSRF may exist in your stack and implement these defense layers in a practical way. Start for free through our Intelligence Center or explore our plans to take your company's security maturity to the next level.