What is SSRF (server-side request forgery)?
Last reviewed
Server-side request forgery (SSRF) is a vulnerability where an attacker coerces a server into making HTTP or other requests to a destination the attacker chooses. It is used to reach internal services, cloud metadata endpoints, and otherwise unreachable systems behind the firewall. Prevention centers on allowlisting destinations and blocking access to internal addresses.
What SSRF is
Server-side request forgery, tracked as CWE-918, occurs when an application fetches a remote resource using a URL or address that it derives from user input, without sufficiently validating where that request is allowed to go. The attacker supplies a destination and the trusted server makes the request on their behalf, often from inside a network the attacker could not otherwise reach.
SSRF rose to prominence as cloud deployments grew, because a server can frequently reach internal-only services and cloud metadata endpoints that hold credentials.
How the attack works
Consider a feature that fetches a user-supplied image URL to generate a thumbnail. Instead of an image, the attacker submits http://169.254.169.254/latest/meta-data/iam/security-credentials/, the link-local address of a cloud instance metadata service. The server dutifully requests it and may return temporary cloud credentials, which the attacker then uses to access cloud resources directly.
Other targets include internal admin panels at addresses like http://10.0.0.5/admin, services bound to localhost, and internal APIs. Attackers also abuse redirects, alternate IP encodings, and non-HTTP schemes such as file:// or gopher:// to bypass naive filters.
Real-world impact
- Theft of cloud credentials from instance metadata services.
- Access to internal services and admin interfaces behind the firewall.
- Internal port scanning and network reconnaissance.
- In some cases, escalation to remote code execution against an internal service.
How to prevent it
Allowlisting is far more reliable than denylisting, because attackers have many ways to encode an internal address that a blocklist will miss.
- Allowlist the exact destinations (hosts, ports, schemes) the feature is permitted to reach, and reject everything else.
- Block requests to private, loopback, and link-local address ranges, including 169.254.169.254.
- Resolve the hostname and validate the resulting IP, then guard against DNS rebinding by validating again at connection time.
- Disable unneeded URL schemes and disable automatic redirect following, or re-validate each redirect target.
- Require credentials on the cloud metadata service (for example IMDSv2) and apply least-privilege roles.
Keep exploring
- CWE-918: Server-Side Request ForgeryThe MITRE weakness entry SSRF maps to.
- What is CSRF?The client-side request forgery with a similar name.
- What is remote code execution?A frequent escalation goal once SSRF reaches internal services.
- Browse the CWE directoryExplore the full catalog of weakness types.
- What is XXE?XML external entity injection and its impact.
- What is an open redirect?Unvalidated redirects abused for phishing.
Frequently asked questions
- What is SSRF in simple terms?
- It is when you trick a server into fetching a URL of your choosing, so it makes requests to internal systems or cloud services that you could not reach yourself.
- Why is SSRF so dangerous in the cloud?
- Cloud servers can reach an instance metadata endpoint that hands out temporary credentials. An SSRF that reaches it can steal those credentials and access cloud resources directly.
- How do you prevent SSRF?
- Allowlist permitted destinations, block private and link-local IP ranges, validate the resolved IP to defeat DNS rebinding, disable risky URL schemes and redirects, and protect the cloud metadata service.
- Which CWE covers SSRF?
- Server-side request forgery is CWE-918, Server-Side Request Forgery (SSRF).