Server-Side Request Forgery
SSRF makes the server fetch attacker-chosen URLs — cloud metadata endpoints, internal admin panels, loopback services — abusing trusted network position to reach what clients never could.
Definition
Server-Side Request Forgery is a flaw where an application issues outbound requests to a URL derived from user input. The server network position trusts requests that external clients cannot make: link-local cloud metadata addresses, internal service ports, and loopback interfaces. Defense combines allowlist egress, DNS pinning, redirect refusal, and metadata hardening.
Context and scope
Exploited against webhook configurators, URL preview generators, importers, PDF renderers, and image fetchers. Post-cloud-SSRF, the top prize is the metadata endpoint handing out credentials.
Common misconceptions
- Blocking private IP literals is enough — DNS rebinding, redirects, and decimal IP encodings evade literal checks
- Only GET-style fetches matter — request methods and headers can be steered too, reaching internal APIs that mutate state
- The impact stops at reading — SSRF yields credentials from metadata endpoints and can pivot into full cloud account takeover
Anti-patterns
- Fetching user-supplied URLs with default DNS resolution and letting rebinding swap to a private address
- Validating the URL once but following redirects to arbitrary destinations
- Allowing arbitrary egress from render or preview services that sit inside the trusted zone
Related concepts
Related examples
Authoritative source
https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
What it is
The server can reach internal networks that browsers cannot. When it fetches a URL the user chose, the user is effectively inside that network. Targets include cloud metadata at link-local addresses returning instance credentials, internal dashboards without authentication, and databases exposing HTTP.
How it works
The attacker submits http://169.254.169.254/latest/meta-data or an internal hostname to a webhook or preview feature. Evasions: redirects from a public host to a private one, DNS answers that change between validation and fetch (rebinding), and alternate IP encodings. Hardening: pin resolved IPs after validation, refuse redirects or re-validate each hop, and require session tokens on metadata endpoints (IMDSv2).
When to defend
Any feature that fetches by URL: link previews, webhook delivery, avatar imports, document renderers. Prefer allowlisting destination domains over blocklisting private ranges — the allowlist cannot be bypassed by an encoding you forgot.
Pitfalls
Egress firewalls that resolve names themselves defeat IP pinning unless the resolver is shared and controlled. Webhook delivery needs outbound access by design: scope it per-tenant with policies. Time-of-check to time-of-use gaps are the recurring root cause — validate and connect in one atomic operation.