Server-Side Request Forgery (SSRF) turns your own server into an attacker’s proxy. It rose into the OWASP Top 10 because of how devastating it has become in cloud environments — SSRF has driven some of the largest breaches on record. This guide explains how it works and how to defend against it.
What SSRF is
SSRF happens when an application fetches a URL that an attacker can influence — an image importer, a webhook, a PDF generator, a link-preview feature. Instead of an external URL, the attacker supplies an internal one, and your server, which sits inside the trusted network, makes the request on their behalf. Suddenly the attacker can reach systems that are not exposed to the internet at all.
Why the cloud makes it critical
Every major cloud provider runs a metadata service at a link-local address (for example 169.254.169.254) that returns configuration and, crucially, temporary credentials to the instance. If an attacker can make your server request that endpoint via SSRF, they can steal those credentials and pivot into your cloud account. This is exactly how several headline cloud breaches unfolded — an SSRF bug plus a metadata endpoint equalled a full compromise.
What attackers reach with SSRF
- Cloud metadata endpoints and their credentials.
- Internal admin panels, databases and services with no external exposure.
- Other hosts on the internal network via port scanning through your server.
- Local files and services via alternative URL schemes (
file://,gopher://).
How to prevent it
- Allowlist the exact destinations the feature legitimately needs, rather than blocklisting bad ones.
- Block private and link-local ranges, and resolve then validate the final IP to defeat DNS-rebinding and redirect tricks.
- Disable unused URL schemes, allowing only
http/https. - Require IMDSv2 (session-based metadata) on AWS, which blocks the simplest SSRF-to-credential path.
- Isolate the fetching service in a network segment with no access to sensitive internals.
Filters are notoriously easy to bypass with redirects, alternate encodings and DNS tricks, which is why validating the resolved destination — not the raw string — matters.
How we test for it
We identify every feature that fetches a URL, then attempt to redirect those requests to internal targets and cloud metadata endpoints, using out-of-band techniques to prove the server actually made the call. This is the focus of SSRF testing, and because SSRF so often lives in API-driven features it overlaps with API penetration testing and any full web application penetration test.
Frequently asked questions
Is SSRF only a cloud problem? No — it is dangerous anywhere with internal services, but the cloud metadata angle makes it especially severe.
Is blocking 169.254.169.254 enough? No. Attackers use redirects, DNS rebinding and alternate representations; you must validate the resolved IP and prefer allowlisting. See the web vulnerabilities we exploit most.
Concerned an import or webhook feature could be abused? Explore SSRF testing or get a fixed-price quote.