SSRF (Server-Side Request Forgery) turns your own server into the attacker's proxy. Anywhere your app fetches a URL someone else provides, an attacker can point it inward, at services that should never be reachable from outside.
How SSRF works
Your app takes a URL and fetches it server-side, to generate a link preview, import data, render a PDF from a page, or call a user-supplied webhook. If you fetch whatever URL you're given, an attacker supplies an internal one:
# Your feature: "import from URL"
POST /api/import { "url": "https://example.com/data.json" }
# The attacker's input:
POST /api/import { "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }
# → your server fetches cloud metadata and may leak credentialsBecause the request originates inside your network, firewalls trust it. SSRF can reach internal admin panels, databases, and (most dangerously) the cloud metadata endpoint (169.254.169.254), which can hand over IAM credentials.
Where SSRF hides
- Webhooks and user-supplied callback URLs
- "Import from URL" / "fetch from link" features
- Link previews and URL unfurling
- PDF/image generators that load remote resources
- Server-side proxies and integrations
How to prevent SSRF
- Allow-list destinations. Only fetch hosts you explicitly permit; reject everything else.
- Block private & reserved IPs. Deny
127.0.0.0/8,10/8,172.16/12,192.168/16, link-local, and the metadata IP169.254.169.254. - Re-check the resolved IP. Resolve the hostname and validate the actual IP after resolution to defeat DNS rebinding.
- Restrict schemes. Allow only
https(andhttpif you must); blockfile://,gopher://, etc. - Don't follow untrusted redirects. A safe URL can 302 to an internal one.
- Use IMDSv2. On AWS, require token-based metadata access to blunt metadata SSRF.
Scan for it
SSRF hides in convenience features nobody thinks of as risky. Connect GitHub and Nurbak scans your code for SSRF-prone endpoints and the rest of the API security checklist, and can open a PR with the fix.
