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) — the entry point of the Capital One breach. How it works, where it hides, the validation pitfalls people miss, and how to defend.
"Paste a URL and we'll fetch its contents" — an everyday convenience that, in the worst case, becomes the door to 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 turns the server into a proxy that hits the inside. Servers can reach internal networks and cloud credential endpoints that are invisible from outside — so an attacker peeks at 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 keys are stolen and the attack chains 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 pitfalls people miss
"Block internal IPs" is not enough. You must close these gaps too.
Naive blocking leaks
- 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 ITD 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 sturdier 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 aim at third-party sites.
Close the gaps and protect metadata
Validate the final redirect target, account for DNS rebinding, and require token-based metadata (e.g. IMDSv2) in the cloud.
ITD builds on "hold no secrets", "diagnose only what's proven-owned", and "minimize the blast radius" (→ About ITD).
Read next
- Glossary: What is RCE · What is a CVE
- Basics: Security basics
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 keys are stolen and the attack chains 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 close the redirect-following and DNS-rebinding gaps.