Learn SSRF the way it's actually exploited — hands-on, against a live target. Turn a harmless URL-preview feature into a doorway to internal services and cloud metadata in the FetchFlow lab.
Server-Side Request Forgery is a vulnerability that lets an attacker make a server issue HTTP requests to destinations of the attacker's choosing. The crucial detail is where the request comes from: because it originates on the server, it inherits the server's network position — reaching internal services, loopback-bound admin panels, and cloud metadata endpoints that are completely unreachable from the public internet.
SSRF hides inside convenient features. Anything that fetches a URL on your behalf — a link-preview generator, a webhook validator, a PDF renderer, an image proxy, an import-by-URL tool — is a candidate. If the destination isn't strictly validated, that helpful feature becomes a pivot into the network.
Admin panels and internal APIs that return 403 to the outside world are often wide open from the server itself. SSRF lets an attacker speak to them directly, bypassing the network boundary that was supposed to protect them.
On cloud platforms, a special link-local address at 169.254.169.254 serves instance metadata — and on some configurations, temporary credentials. SSRF that reaches it can escalate from a web bug to cloud account access.
SSRF is significant enough to hold its own dedicated slot — A10:2021 – Server-Side Request Forgery — in the current OWASP Top 10. It was promoted into the list in the 2021 revision because of how common and how damaging it has become in cloud-hosted applications. The impact classes below are what earn it a high-severity rating.
| Impact | What the attacker gains | Severity |
|---|---|---|
| Internal service access | Reach loopback-bound admin panels and APIs | High |
| Cloud metadata | Query the instance metadata endpoint | High |
| Internal port scanning | Map which internal ports are open by response diffing | Medium |
| Credential theft | Retrieve temporary IAM credentials on some platforms | High |
The core lesson of Room 8 is that automation and human judgment are a pipeline, not a competition. An autonomous scan maps the attack surface in minutes — the exposed paths, the forbidden endpoints, the open ports. But SSRF is interaction-based: it only reveals itself when you craft a request and watch where the server actually goes. That's the gap a human closes.
In the lab, you run a real PhantomRed scan against FetchFlow, read the findings it surfaces, then take over manually to prove the SSRF the scanner can't see:
Room 9 takes this a step further with a dedicated XXE lab, where an XML parser can be turned into an SSRF primitive — the two vulnerability classes chain together directly.
The FetchFlow lab is live and free to play. Run a real autonomous scan, then exploit the SSRF the scanner can't see — reach the internal admin panel and the cloud metadata endpoint, end to end.