SSRF: Making the Server Attack Itself
SSRF turns your trusted server into the attacker's proxy. In the cloud, one vulnerable fetch can hand over the credentials to your entire account. Here is how it happens and how to stop it.
Server-Side Request Forgery (SSRF) is a flaw where an attacker can make the server issue HTTP requests to a destination of their choosing. Because the request originates from inside your infrastructure, it often reaches places the attacker never could directly - internal APIs, admin panels, and cloud metadata endpoints.
How it works
Any feature that fetches a URL is a candidate: webhooks, "import from URL," link previews, PDF generators, image proxies. Suppose an app fetches a user-supplied image URL:
POST /import
url=https://example.com/photo.jpg -> server fetches itSwap the value for an internal address and the server obeys:
url=http://localhost/admin
url=http://192.168.0.10:8080/internal-apiThe attacker now reads internal-only services through your server, bypassing the firewall entirely.
The cloud metadata jackpot
On AWS, Azure, and GCP, instances expose a metadata service at the link-local address 169.254.169.254. On a legacy AWS setup (IMDSv1) an SSRF can simply request the role credentials:
url=http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>That returns temporary AWS access keys for the instance's IAM role. With those, the attacker walks straight into your cloud account with whatever permissions the role holds. This exact chain is behind some of the largest cloud breaches on record.
SSRF is dangerous precisely because the request is trusted. Internal services that assume "if it came from our own network it must be safe" hand over the keys without a second thought.
Blind SSRF and pivoting
Even when the response is never shown back to the attacker (blind SSRF), it is still useful: response timing and error differences reveal which internal hosts and ports are alive, effectively giving the attacker a port scanner positioned inside your perimeter. Combined with an exploitable internal service, blind SSRF becomes a foothold.
How to prevent it
- Allowlist, don't blocklist. Permit only the specific domains/IPs the feature legitimately needs. Blocklists are trivially bypassed with redirects, DNS rebinding, alternate IP encodings, and IPv6.
- Block private and link-local ranges at the application and network layer:
127.0.0.0/8,10/8,172.16/12,192.168/16, and169.254.0.0/16. - Resolve then validate. Resolve the hostname, check the resulting IP against your allowlist, and pin that IP for the actual request to defeat DNS rebinding.
- Disable HTTP redirects on server-side fetchers, or re-validate the target after every redirect.
- Enforce IMDSv2 on AWS (session-token required) and put outbound egress controls in front of workloads.
Key takeaways
- SSRF makes your server fetch attacker-chosen URLs from inside the perimeter.
- Cloud metadata theft can escalate one bug into full account compromise.
- Blind SSRF is still a working internal port scanner.
- Allowlist destinations, block internal ranges, and require IMDSv2.
Unnbugify provides consent-based VAPT, red teaming, cloud and API security testing, and secure code review for organisations of every size.