Server-Side Request Forgery (SSRF) has been in the bug bounty playbook for years, but it hasn’t lost its bite. If anything, the move to cloud infrastructure has made it more valuable.
The mechanic is simple: you trick a server into making a request it shouldn’t. Point it at an internal service, a metadata endpoint, or a hidden API, and suddenly you’re getting responses meant only for the backend.
What makes SSRF dangerous is scope. A single endpoint that fetches a user-supplied URL can pivot into:
stealing AWS/GCP/Azure credentials,
hitting internal admin panels,
scanning the company’s private network from the inside.
That’s why programs still pay well for SSRF. It’s not an abstract vulnerability. SSRF is a of the clean path from “minor bug” to “critical business impact.”
0x01 How SSRF Works
At its core, SSRF abuses trust in user-supplied URLs. The application accepts an external link, fetches it on the server side, and returns the response. If that URL isn’t validated, you control where the server reaches out.
Simple Example
@app.route('/fetch-data')
def fetch_data():
url = request.args.get('url')
response = requests.get(url)
return response.text
Intended use:
GET /fetch-data?url=https://api.partner.com/user-info
Exploitation:
GET /fetch-data?url=http://169.254.169.254/latest/meta-data/
Instead of calling a partner API, the server exposed its cloud metadata service.
Why It Works
Developers often assume the server’s internal network is safe. SSRF breaks that assumption. If you can direct the server’s requests, you inherit its reach; internal services, cloud metadata, and microservices behind the firewall.
0x02 Modern SSRF Attack Surface
SSRF doesn’t just hide in /fetch?url= endpoints. Modern applications are full of features that make server-side calls for convenience — and every one of them is a potential vector.
Common Features That Leak SSRF
PDF generation: render a remote HTML template.
Webhook processing: post event data to a user-supplied callback URL.
Image fetchers: grab avatars or banners from external sources.
Importers: pull data or feeds from third-party links.
Anywhere a developer thought, “let’s fetch that for the user”, SSRF is lurking.
Cloud Impact
In cloud environments, SSRF goes from bad to critical. A single request to the metadata service can dump credentials tied to the instance:
AWS:
http://169.254.169.254/latest/meta-data/iam/security-credentials/GCP:
http://metadata.google.internal/computeMetadata/v1/Azure:
http://169.254.169.254/metadata/instance
SSRF Attack Chain
Find vulnerable endpoint.
Use it to reach the cloud metadata service.
Extract temporary credentials.
Pivot into cloud resources with stolen access keys.
That’s why SSRF consistently lands high payouts: the jump from a single HTTP request to full infrastructure compromise is short and very real.
0x03 Hunting for SSRF in the Wild
Finding SSRF isn’t about luck — it’s about spotting where applications fetch data on your behalf. The trick is to identify those inputs, then confirm the server is actually making outbound calls.
Start simple:
Point the parameter to your own server and watch for callbacks (Burp Collaborator, Interactsh, or your own listener).
Probe internal IPs (
127.0.0.1,169.254.169.254) and common ports.Watch for error messages: responses mentioning localhost, metadata, or connection refused.
Signals of SSRF
Unexpected timeouts or delays.
Error messages that leak backend hostnames.
Responses containing sensitive keywords like
ami-id,instance-id,kubernetes.
Automating Discovery
Fuzz parameters with URL payloads and track responses:
for target in ["http://127.0.0.1", "http://169.254.169.254", "http://metadata.google.internal"]:
test_ssrf(f"https://target.com/fetch?url={target}")
A simple loop like this can light up an SSRF in minutes.
0x04 Common Impact Scenarios
Not all SSRF is equal. Pulling in
http://example.com
isn’t interesting. Pivoting into internal or cloud-only services is where the real impact lives.
Internal Services
Many organizations expose sensitive tools internally without hardening them:
jenkins.internal:8080— build server control.kubernetes.default.svc— Kubernetes API from inside the cluster.mongodb://localhost:27017— open database.redis://internal-cache:6379— cache poisoning or data theft.
Cloud Metadata
Metadata endpoints hand out temporary credentials tied to the instance:
AWS:
http://169.254.169.254/latest/meta-data/iam/security-credentials/GCP:
http://metadata.google.internal/computeMetadata/v1/Azure:
http://169.254.169.254/metadata/instance
One request can escalate into full cloud resource access.
Internal Network Mapping
Even if you don’t extract secrets, SSRF can act as a proxy to scan the company’s private network:
for port in [21,22,80,443,8080]:
try_ssrf(f"http://10.0.0.5:{port}")
SSRF turns the target’s server into your scanner, reaching places you never could directly.
Realistic Payouts
Cloud provider SSRF → AWS creds theft: $15,000
E-commerce platform SSRF → Kubernetes API access: $7,500
Financial service SSRF → internal service enumeration: $5,000
The money scales with impact: the closer you get to sensitive services or credentials, the bigger the payout.
0x05 Bypassing Protections
Most applications don’t leave SSRF wide open. Developers try to bolt on filters — but those filters are usually brittle. Knowing how they break is what separates a low-value bug from a critical report.
Naive Domain Checks
def is_safe_url(url):
return url.startswith("https://api.internal")
Bypass with DNS:
api.internal.attacker.comBypass with userinfo:
https://api.internal@evil.comIP Filtering
Apps try to block internal IPs like 127.0.0.1 or 169.254.169.254.
Bypass with DNS rebinding: domain resolves externally at first, then to an internal IP.
Bypass with encoding: use octal, hex, or IPv6 formats for localhost.
Redirect Abuse
Even if direct requests are blocked, open redirects can bounce the request into forbidden territory.
Alternate Protocols
Some libraries support more than http/https:
Gopher: interact with internal TCP services.
File: read local files from disk.
Lesson
Filters are just string handling. Regex and allowlists rarely cover every edge case. If you hit a wall, shift the syntax — SSRF defenses are fragile by design.
0x06 Reporting SSRF for Maximum Payout
SSRF findings can swing wildly in payout value. The same bug might earn $500 as “low impact” or $15,000 as “critical.” The demonstrated impact and thoughtful reporting can make a difference.
Structure the Story
Frame the report as a chain, not just a single request.
Vulnerable endpoint (
/fetch?url=).Proof of SSRF with controlled callback.
Escalation to internal/cloud targets.
Business impact: credential theft, service compromise, or data exposure.
Demonstrate Real Impact
Don’t stop at “I can fetch a URL.”
Show how an attacker pivots to AWS/GCP/Azure metadata.
Demonstrate enumeration of internal services.
Highlight lateral movement potential (e.g., Kubernetes API).
Keep it clean: proof of concept only. Never include raw credentials or sensitive customer data.
Anticipate Pushback
Security teams often downplay SSRF:
“It requires authentication.” — Show how a normal user could abuse it.
“No sensitive data exposed.” — Map out what could be reached if exploited fully.
“Informational.” — Tie it back to business risk, not just technical behavior.
Present Professionally
Minimal PoC code (one curl, one script).
Sanitized requests/responses.
Screenshots before/after.
Executive summary that management can understand.
A triager should finish your report convinced that the vulnerability is real.
0x07 Debrief - SSRF for Payouts
SSRF is an of the old trick in web security, but it hasn’t lost its edge. In cloud-heavy environments, a misconfigured fetch can pivot straight into credential theft or internal compromise.
The technique itself is simple. The craft lies in persistence: spotting hidden fetches, bypassing weak filters, chaining small SSRFs into big impact, and writing reports that programs can’t dismiss.
In bug bounty, SSRF rewards those who treats every URL parameter and server-side fetch as a door worth testing. Most of them will be locked. But the one that opens can expose an entire infrastructure.