Cybersecurity glossary
What is Server-Side Request Forgery (SSRF)?
Learn what Server-Side Request Forgery (SSRF) is, how attackers make servers fetch internal URLs, why cloud metadata is a common target, and how to prevent SSRF with allowlists and network controls.
Definition
Server-Side Request Forgery (SSRF) is a vulnerability in which an attacker causes a server to make HTTP or other network requests to unintended destinations—often internal services or cloud metadata endpoints—by supplying or influencing request URLs.
Why SSRF matters
Applications frequently fetch URLs: link previews, webhooks testing, PDF generators, import-from-URL features, and image proxies. When attackers control those URLs, the server becomes a proxy into networks the attacker cannot reach directly.
Server-Side Request Forgery (SSRF) has powered serious cloud breaches by reaching instance metadata services and internal admin panels. It is both an application bug and a network-architecture problem.
How SSRF works
Find a server-side fetch feature
Locate parameters that cause the server to request a URL or hostname.
Point at an unintended target
Supply internal IPs, metadata endpoints, or other restricted hosts.
Bypass naive filters
Use redirects, DNS tricks, alternate IP encodings, or allowed-looking hostnames.
Server initiates the request
From its privileged network position, the application connects to the target.
Extract data or credentials
Responses, errors, or timing reveal internal content; metadata may yield tokens.
Pivot deeper
Stolen credentials or internal access expand into broader cloud or network compromise.
Common targets and impacts
Cloud metadata
169.254.169.254-style services that expose temporary cloud credentials.
Internal admin apps
Services bound to private networks assuming they are unreachable.
Localhost daemons
Redis, Docker APIs, or debug ports listening on 127.0.0.1.
Port scanning
Mapping internal hosts via response timing and error differences.
Prevention strategy
| Layer | Controls |
|---|---|
| Design | Prefer non-URL identifiers; do not fetch arbitrary user URLs |
| Validation | Allowlist hosts/schemes; pin expected destinations |
| Resolution checks | Block private, loopback, link-local, and metadata ranges after DNS resolve |
| Network | Egress-restrict application fetchers; isolate metadata access (IMDSv2 etc.) |
| Response handling | Do not relay raw internal responses to clients |
- Inventory every feature that causes server-side outbound requests.
- Default-deny destinations; allowlist only required external hosts.
- Re-check IPs after DNS resolution and disable redirects or revalidate them.
- Block access to cloud metadata from app roles; require IMDSv2/session tokens where applicable.
- Run URL fetchers in dedicated workers with strict egress firewalls.
- Disable obscure URL schemes in HTTP clients.
- Monitor unusual outbound destinations from application subnets.
- Include SSRF cases in pentests for preview/import/webhook features.
The practical takeaway
SSRF makes your server request attacker-chosen destinations, often exposing internal networks and cloud credentials. Fixing it requires both safe URL handling and network isolation.
If users can make your servers fetch URLs, assume they will aim those fetches at everything your servers can reach—and shrink that reach aggressively.
Related security terms
Remote File Inclusion (RFI)
A related server fetch pattern focused on including remote code.
DNS Rebinding
A technique sometimes used to bypass naive SSRF host allowlists.
Web Application Firewall (WAF)
Can detect some SSRF payloads but should not replace architectural fixes.
API Abuse
URL-fetching features are common API capabilities that need SSRF controls.
Frequently asked questions
What is SSRF in simple terms?
SSRF tricks your server into calling URLs chosen by an attacker. Instead of the attacker scanning your internal network directly, your server does it for them.
Why is cloud metadata a common SSRF target?
Cloud instance metadata services are reachable from the server and can expose temporary credentials. SSRF that can hit those endpoints may steal cloud access.
Is SSRF only about HTTP?
HTTP is most common, but SSRF can involve other schemes or protocols if the application or library supports them (file, gopher, dict, and similar historically).
How do attackers bypass SSRF filters?
They use DNS rebinding, decimal/hex IPs, redirect chains, IPv6 forms, alternative hostnames, and open redirects to reach blocked destinations.
How do you prevent SSRF?
Avoid user-controlled URLs when possible, allowlist destinations, block link-local/metadata ranges, disable dangerous schemes, and place fetchers in firewalled network segments.
Does a URL allowlist of https only stop SSRF?
No. HTTPS to an internal host or to a metadata IP via unexpected name resolution can still be dangerous. Validate resolved addresses too.
What is blind SSRF?
Blind SSRF occurs when the attacker cannot see the response body but can still trigger requests—sometimes detected via timing or out-of-band callbacks.
References
Explore authoritative guidance and frameworks related to server-side request forgery (ssrf).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.