Server-Side Request Forgery (SSRF)
SSRF is a vulnerability where an attacker makes the server send HTTP requests to a destination of their choosing. Instead of the app fetching the URL it should, it fetches one the attacker controls — turning the trusted server into a proxy into internal networks.
Why it matters
- Reach internal services firewalled off from the internet (
localhost,10.x,192.168.x). - Hit cloud metadata endpoints (e.g.
169.254.169.254) to leak IAM credentials. - Port-scan the internal network and pivot deeper.
- Blind SSRF can still exfiltrate via DNS/timing side channels.
Where it hides
Any feature where the server fetches a user-supplied URL:
- Webhooks & callback URLs
- "Import from URL" / avatar-from-link uploads
- PDF / screenshot / thumbnail generators
- URL preview and link-unfurling
- XML parsers (XXE → SSRF)
Classic smell test: a parameter like ?url=, ?dest=, ?image=, ?feed= that the backend reaches out to.
Defending against it
- Allowlist, don't blocklist — permit only known-good hosts/schemes.
- Resolve the hostname, then validate the resolved IP against private/reserved ranges (defeats DNS-rebinding & redirects).
- Disable unneeded URL schemes (
file://,gopher://,dict://). - Block cloud metadata IPs at the network layer; require IMDSv2.
- Don't follow redirects blindly; re-validate every hop.
- Isolate the fetching service in a locked-down egress segment.