SSRF Explained: How to Find and Exploit Server-Side Request Forgery (Responsibly)

SSRF — Server-Side Request Forgery — is one of the highest-impact bugs a bounty hunter can find, because it turns the target’s own server into your proxy. Instead of you making requests from the outside, you trick the application into making them from the inside, where it can reach cloud metadata services, internal admin panels, and databases that are firewalled off from the internet. A good SSRF can go from “a URL field accepted my input” to “here are the server’s cloud credentials.” This guide covers what SSRF is, where it hides, how to confirm it, and how to escalate it — responsibly.

What SSRF actually is

SSRF happens when an application takes a URL (or hostname, or IP) from user input and makes a server-side HTTP request to it without properly restricting where it can go. The classic example: an app has a feature to fetch an avatar from a URL you provide.

POST /api/profile/avatar
{ "imageUrl": "https://example.com/me.png" }

You control imageUrl. What if you point it at http://169.254.169.254/ instead? If the server blindly fetches whatever you give it, it just made a request to the cloud metadata service on your behalf — from inside the trusted network. That’s SSRF.

Why SSRF is so dangerous

The server sits in a privileged network position you don’t have. A working SSRF lets you borrow it:

• Cloud metadata → credentials. On AWS, http://169.254.169.254/latest/meta-data/iam/security-credentials/ returns temporary IAM keys for the instance’s role. GCP and Azure have their own metadata endpoints (GCP requires the header Metadata-Flavor: Google). Stolen instance credentials are frequently the path from “SSRF” to “cloud account takeover.”
• Internal services. Admin panels, dashboards, databases, and message queues that are only reachable from inside — Redis, Elasticsearch, internal APIs, Kubernetes’ API server — become reachable through the vulnerable server.
• Internal port scanning. By observing response times or errors for different ports, you can map the internal network.

That range of impact is why SSRF regularly pays top-tier bounties and appears in the OWASP Top 10.

Where SSRF hides — the features to hunt

Any feature that makes the server fetch something is a candidate. Look for:

• URL fetchers: avatar/image-from-URL, “import from URL,” link previews, RSS/feed readers.
• Webhooks: “send events to this URL” — you supply the destination, the server calls it.
• Document/media processors: HTML-to-PDF generators, website screenshotters, image proxies/resizers. These fetch remote resources server-side and are SSRF goldmines.
• Integrations that take a URL: “connect your instance,” SSO/OAuth flows that fetch metadata (jwks_uri, logo_uri, OpenID discovery URLs), and file-upload-from-URL.
• Parsers: XML with external entities (XXE can become SSRF), and SVG files, which can reference remote resources.

Whenever you see a parameter that holds a URL, a hostname, or something that becomes one, flag it. A useful trick: replace the value with a unique sentinel you control and watch whether your server gets a hit.

How to confirm SSRF (including the blind kind)

The reliable way to detect SSRF — especially blind SSRF, where the response isn’t shown back to you — is an out-of-band (OOB) callback. Use Burp Collaborator, an interactsh server, or any domain whose DNS/HTTP logs you can see:

# Point the vulnerable field at a unique callback host
https://YOUR-UNIQUE-ID.oast.site/

# Then watch for an incoming DNS lookup / HTTP request from the target's server IP

If your callback server records a hit sourced from the target’s infrastructure, the server made the request — SSRF confirmed. If the app returns the response body to you (full-response SSRF), even better: you can read what internal endpoints say. If it doesn’t (blind SSRF), you rely on OOB signals and timing.

Escalation: from callback to impact

A DNS callback proves SSRF exists, but a report needs impact. Escalate toward the sensitive targets:

• Cloud metadata: try http://169.254.169.254/latest/meta-data/ (AWS), the GCP metadata endpoint with its required header, and Azure’s. Reaching IAM credentials is a critical finding.
• Localhost and internal ranges: http://127.0.0.1/, http://localhost/, and internal RFC 1918 ranges (10.x, 192.168.x, 172.16–31.x) to hit admin interfaces and internal apps.
• Protocol smuggling: where the fetcher allows non-HTTP schemes, gopher:// can craft raw TCP payloads (to talk to Redis or send an internal HTTP request), and file:// may read local files. dict:// is another option for some services.

Getting past filters

Many apps try to block SSRF, and many do it badly. Common bypasses for weak blocklists that only check for “127.0.0.1” or “localhost”:

• Alternate IP encodings of 127.0.0.1: decimal 2130706433, octal 0177.0.0.1, hex 0x7f000001, and shorthand 127.1.
• Alternate localhost spellings: 0.0.0.0, [::], and IPv6 loopback [::1].
• Redirect-based bypass: point the fetcher at a URL you control that returns a 301/302 redirect to 169.254.169.254 — the app validates your harmless domain, then follows the redirect to the forbidden target.
• DNS rebinding: a hostname that resolves to a safe IP at validation time and to an internal IP when the request is actually made.
• The URL-parser tricks: @ (userinfo) confusion like http://expected.com@169.254.169.254/, and malformed URLs that the validator and the HTTP client parse differently. (PortSwigger’s URL-parsing cheatsheet is worth running in full.)

The theme: the validator and the code that actually makes the request often disagree about what a URL means. That gap is where SSRF bypasses live.

Reporting SSRF well

State the endpoint, the exact request that triggers it, and the strongest impact you demonstrated — a DNS callback is good, reaching internal-only content is better, and pulling cloud metadata/credentials is critical. Note whether it’s blind or full-response, and one line of remediation: validate destinations against an allowlist, resolve the hostname and check the resolved IP is not internal, block redirects to internal ranges, and disable unused URL schemes. Never actually use stolen credentials or pivot into systems — demonstrating you could reach metadata is the finding; abusing it crosses a hard line.

The bottom line

SSRF is the art of making the server fetch things it shouldn’t, from a network position you don’t have. Hunt every feature that takes a URL, confirm with an out-of-band callback, and escalate toward cloud metadata and internal services — while getting past naive filters with alternate encodings and redirects. It’s a top-tier class precisely because a single overlooked URL field can hand you the keys to the internal network. Find them carefully, prove impact cleanly, and report responsibly.

---

Test only systems you are explicitly authorized to assess. SSRF against out-of-scope infrastructure — and especially any use of credentials or access it exposes — is illegal. Demonstrate reachability, then stop.