Glossary
What is SSRF (Server-Side Request Forgery)
SSRF makes a server send requests to internal destinations it shouldn't reach (internal IPs, cloud metadata). It was the cause of the Capital One breach. How it works, where it hides, the validation gaps people miss, and how to defend.
A feature that fetches the contents of a pasted URL is an everyday convenience, but in the worst case it exposes your cloud credentials. That's SSRF. Here's how it works and how to defend, from zero.
What's actually happening
Normal access is "user → external site". SSRF makes the server send requests to internal destinations on the attacker's behalf. Servers can reach internal networks and cloud credential endpoints that are invisible from outside, so an attacker can read them indirectly.
169.254.169.254 (cloud credentials)In the cloud, that internal endpoint (the metadata service) can hand out temporary credentials. If SSRF reaches it, the credentials are stolen and the attack leads to wholesale storage exfiltration, which is exactly what happened in the Capital One breach (2019): SSRF → metadata → IAM credentials → S3.
Where it hides
Any feature where "a server fetches a user-supplied URL" is a candidate.
| Feature | Typical implementation |
|---|---|
| OG / link preview | server fetches a pasted URL to build a thumbnail |
| Webhook delivery | server POSTs to a user-specified destination |
| Image / file import | "fetch an image from a URL" |
| Site diagnostics | server accesses the entered site to inspect it |
Validation gaps people miss
"Block internal IPs" is not enough. You must also handle these bypasses.
Naive blocking is not enough
- Redirect following: an allowed domain
302s to an internal address. - DNS rebinding: external IP at validation time, internal IP at fetch time.
- IP encoding tricks: decimal/octal/short forms disguise an internal address.
- Odd schemes:
file://,gopher://and other unexpected schemes.
How to defend if you build the feature
SSRF is prevented in "how you build the feature". These are the rules this site imposes on its own diagnostic features.
Use an allowlist for destinations
Restrict scheme (http/https) and host to an allowed set only. "Allow only these" is more reliable than "block the internal ones".
Block internal targets
Deny reachability to 127.0.0.1 / 10.x / 192.168.x / 169.254.169.254 (metadata).
Only domains the user owns (for diagnostics)
Restrict to domains the user has proven they own. Don't let them target third-party sites.
Handle bypasses and protect metadata
Validate the final redirect target, account for DNS rebinding, and require token-based metadata (e.g. IMDSv2) in the cloud.
This site builds on "hold no secrets", "diagnose only what's proven-owned", and "minimize the damage any compromise can do" (→ About this site).
SSRF vs CSRF vs open redirect
All three involve a destination chosen from outside, but they differ in what moves and how far it reaches.
| Attack | Who goes where | What it can reach |
|---|---|---|
| SSRF | Your server sends a request to the destination it was given | Places unreachable from outside, such as the internal network and cloud credentials |
| CSRF | The user's browser sends a request the user did not intend | Whatever the user can do on a site where they are logged in |
| Open redirect | The user's browser is forwarded to the external site it was given | A fake site (phishing) |
SSRF is especially dangerous because what it reaches is "inside the server." Places your firewall protects from the outside can still be reached through the server.
Real examples: it hides in framework features too
SSRF shows up not only in "fetch this URL" features you write yourself, but also in framework features. In recent Next.js CVEs, for example, SSRF (CWE-918) is among the most common weakness types, in server features such as image optimization that fetch external images (→ Next.js and React vulnerabilities in real data). In MITRE's "CWE Top 25" (the 25 most dangerous software weaknesses), published in December 2025, SSRF ranks 22nd.
In the cloud, the Capital One breach is the standard example. SSRF reached the metadata service, and temporary credentials with excessive permissions were stolen. In November 2019, AWS released IMDSv2 to reduce this kind of damage.
How to check your own environment
List every place that fetches a URL it is given
Search your code for HTTP clients (fetch, axios, requests and so on) whose destination can include user input. Link previews, webhooks, image imports, PDF generation and import features are typical.
Check framework allow settings
In image optimization or external fetch settings, check that the hosts allowed are not too broad (for Next.js, that images.remotePatterns does not contain a wildcard-only entry).
Require IMDSv2 (AWS)
In each EC2 instance's metadata options, check that HttpTokens is required (IMDSv2 only). On servers that do not run containers, keep the token response hop limit at 1.
Restrict the server's outbound traffic
Run URL-fetching code in a separate environment that cannot reach the internal network, or limit outbound traffic to the destinations it needs. If the app's validation misses something, the network still stops it.
Sources (primary)
- OWASP, "Server-Side Request Forgery Prevention Cheat Sheet" — cheatsheetseries.owasp.org (allowlists, blocking internal addresses, handling redirects and DNS)
- AWS, "Use the Instance Metadata Service to access instance metadata" — docs.aws.amazon.com (IMDSv2 session tokens, the required setting, hop limit)
- AWS Security Blog, "Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service" (November 2019) — aws.amazon.com
- Microsoft, "Azure Instance Metadata Service" — learn.microsoft.com (Azure also uses 169.254.169.254)
- MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses" (December 2025) — cwe.mitre.org (CWE-918 ranked 22nd)
Read next
- Glossary: What is RCE · What is a CVE
- Basics: Security basics
- Defense: X-Forwarded-For spoofing and trusted proxies
Classification
CWE classifies the types of weakness behind vulnerabilities; MITRE ATT&CK classifies attacker techniques. Both are maintained by MITRE and widely used to label vulnerability reports and detection rules.
CWE (weakness type)
CWE™: Copyright © 2006–2026, The MITRE Corporation. CWE is a trademark of The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE Terms of Use
FAQ
QWhat kind of features tend to have SSRF?
Features where 'a server fetches a user-supplied URL': OG/link preview generation, webhook delivery, image import, site diagnostics. The more convenient the feature, the more care it needs.
QWhy is SSRF especially dangerous in the cloud?
Cloud VMs have an internal-only 'metadata endpoint' that can hand out temporary credentials. If SSRF reaches it, those credentials are stolen and the attack leads to wholesale storage exfiltration (the path of the Capital One breach).
QHow do I defend against SSRF?
Validate destinations strictly with an allowlist and block reachability to internal IPs (127.0.0.1, 10.x, 169.254.169.254 metadata). For diagnostics, restrict to domains the user has proven they own, and handle redirect-following and DNS-rebinding bypasses.
QWhat is the difference between SSRF and CSRF?
Who sends the request. CSRF makes a user's browser send a request the user did not intend. SSRF makes your server send a request to a destination it should never reach. CSRF damage is limited to what that user can do; SSRF damage extends to whatever the server can reach, such as the internal network or cloud credentials.
QDoes IMDSv2 prevent SSRF?
It greatly narrows the path to stealing cloud credentials, but it does not prevent SSRF itself. AWS IMDSv2 only returns metadata with a session token obtained via a PUT request, so a simple SSRF that just fetches a URL has a hard time reaching the credentials. Reaching internal admin screens or internal APIs is a separate problem, so you still need a destination allowlist and blocking of internal addresses.
QWhat is 169.254.169.254?
An internal-only (link-local) address that cloud virtual machines use to read their own settings and temporary credentials. AWS, Azure and Google Cloud all use it. It cannot be reached from outside, but the server itself can reach it, which makes it the most targeted destination in SSRF.