Server-Side Request Forgery is the bug where a server fetches a URL the attacker chose. The web app intends to support legitimate URLs — an image to preview, a webhook to call, a remote document to import — but it doesn't validate what the URL points to. The attacker uses the server as a proxy to reach things the attacker couldn't reach themselves: internal services, cloud metadata, localhost-only admin pages.
The playground below simulates the Heliotrope Image Preview API. It accepts a URL and "fetches" it server-side. Try the payloads. Toggle defenses on and watch the same payloads start failing.
Mode
Enter a URL. The server fetches it and returns the response. The intended use is previewing image thumbnails from external CDNs.
What the defenses do
The "Defended" mode applies four layers. Each closes a specific class of bypass:
- Scheme allow-list. Only
http://andhttps://are accepted.file://,gopher://,dict://,ldap://are rejected up front. - Host allow-list. Only known-good CDN hosts are accepted (
cdn.example.com,images.example.com). Anything else rejected. - Network egress filter. Even if a URL passed the allow-list, the actual outbound connection is gated by an iptables rule that blocks RFC 1918 (private) ranges, link-local (169.254.0.0/16), and loopback. The instance metadata IPs are unreachable from this app's network namespace.
- Re-resolution at connect. The validator resolves the hostname once, locks the IP, and connects to that exact IP — defeating DNS rebinding where a hostname resolves to a public IP at validation time and a private IP at connect time.
Why SSRF is the cloud-era's favorite bug
- It's everywhere. Any feature that accepts a URL is potentially SSRF: image fetchers, webhooks, URL preview generators, PDF renderers, RSS importers, "Sign in with..." callbacks that fetch JWKS, link unfurlers.
- The payoff is enormous. Reaching the cloud's instance metadata service hands the attacker temporary IAM credentials with whatever permissions the workload role has. The 2019 Capital One breach is the canonical example.
- It's hidden from web scanners. Traditional scanners look for client-side reflection. SSRF is server-side — the attacker watches a side channel (response timing, content length, error messages) to confirm the request happened.
SSRF turns the application server into the attacker's proxy. Whatever the server can reach from its position in the network — private services, the cloud metadata endpoint, the database with no public IP — the attacker can now reach by tricking the application into making the request.
The defense is layered: validate the URL at the application layer, resolve and lock the IP at connect, block the metadata IP at the network layer, require IMDSv2 so the metadata endpoint itself rejects SSRF-style requests. Each layer closes a specific bypass. Together they make the bug class very hard to exploit.
References
Formatted in APA 7. Alphabetized by first author's last name.
- Amazon Web Services. (n.d.). Configure the Instance Metadata Service (IMDSv2). AWS EC2 User Guide. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
- OWASP Foundation. (2021). OWASP top 10: A10:2021 Server-side request forgery. https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
- OWASP Foundation. (n.d.). Server-side request forgery prevention cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
- U.S. Department of Justice. (2019, July 29). Seattle tech worker arrested for data theft involving large financial services company [Press release]. https://www.justice.gov/usao-wdwa/pr/seattle-tech-worker-arrested-data-theft-involving-large-financial-services-company