A URL parameter that looks harmless — avatar_url, webhook, feed, next — can quietly turn into a key to your target's internal network. Server-side request forgery (SSRF) happens when an application fetches a resource for you and lets you choose where it goes. Nothing crashes. No alert fires. The server simply makes a request you control, from a spot inside the perimeter where you were never meant to stand. That is why SSRF keeps landing in high-severity bounty reports: the bug is small, the blast radius rarely is.
The pattern is always the same: user-supplied input reaches an HTTP client, a file loader, or an XML parser without a strict destination check. What changes is the sink.
Watch for features that fetch by nature — webhook test buttons, "import from URL" uploaders, link previews and open-graph unfurlers, RSS and sitemap readers, PDF or screenshot renderers, SSO metadata fetchers, image resizers that accept remote sources, and integrations that pull data from third-party endpoints. Then there are the indirect ones: XML parsers vulnerable to external entities, template engines, and anything that processes a URL inside an archive or document you uploaded.
The distinction that matters during triage is that SSRF is broader than a normal web request. If you can change the scheme, you leave HTTP behind entirely and step into file, gopher, dict, or ftp — which is where the interesting exploitation usually starts.
The application returns the fetched body to you. You point it at an internal service and read the answer in the response. Fast, obvious, and increasingly rare — but when it exists, it is the easiest path to internal discovery.
Nothing comes back. You only know the request happened because your external listener received a DNS lookup or an HTTP hit. Blind SSRF is still valuable: it proves the server can be steered, and it can often be escalated through timing or side effects.
You see fragments — an error message, a stack trace, a response length that changes with the target port, or a delay that betrays an open service. This is the most common real-world case and the one where patient testing pays off.
Most defenses are blocklists and quick regexes. A short list of variants gets past a surprising number of them:
Combine them. A filter that strips localhost but not decimal notation, a WAF that blocks 169.254.169.254 but not an open redirect, or an allowlist that resolves hostnames once and connects later — all of these fall to layered tricks rather than a single clever string.
A callback alone is a low-severity finding on many programs. Credentials are a different story. The 2019 Capital One breach remains the case study most hunters know: a misconfigured web application firewall was abused to reach the AWS instance metadata service and retrieve credentials tied to an S3 bucket.
On AWS, an unauthenticated GET to the metadata path under /latest/meta-data/iam/security-credentials/ can return temporary keys when IMDSv1 is still enabled. Azure and GCP require a specific header with the metadata request, so they are only reachable when your sink can inject headers — which is exactly why CRLF and gopher tricks matter.
Internal services are just as rewarding. A reachable Redis on 6379 can be driven through a gopher payload of URL-encoded protocol commands to write files or load modules. The Docker daemon on 2375, an unauthenticated Kubernetes kubelet on 10250, Elasticsearch on 9200, Consul on 8500, Jenkins, and Spring Boot actuator endpoints are all classic escalation targets. Any of those, plus a way to write a file, is often a route to remote code execution.
If you find SSRF in a program with no cloud infrastructure, look sideways instead: internal dashboards, Grafana, Kibana, Prometheus, and internal APIs that trust anything originating from inside the network. Network trust is the vulnerability.
Prove the chain, then stop. Extracting credentials to demonstrate account takeover is not required — and on most programs, it will get your report closed rather than paid.
Write the report as a story with three parts: how the input reaches the fetch, what you proved you could reach, and what that reach means for the business. Screenshots of a metadata response with keys half-redacted land better than a wall of payloads. Include the exact parameter, the request, the timestamp, and a minimal reproduction. Suggest the fix too: an allowlist of outbound destinations, resolve-then-validate-then-connect logic, blocking non-HTTP schemes, disabling redirects, enforcing IMDSv2, and segmenting egress traffic at the network layer.
Then keep hunting. SSRF hides in features added six months after launch, in integrations nobody reviewed, and in previews that developers assume are harmless. Stay inside scope, keep your probing light, and check the program's rules before you touch internal services. A clean, well-evidenced SSRF report is one of the few that can go from a single URL parameter to a critical rating — and that is worth the patience it takes to find one.
Photo: 12019 / Pixabay
CVSS turns a vague severity opinion into a defensible number. Here is how the metrics work, how to build a vector,...
A practical roadmap for leaving a salaried IT security role for full-time bug bounty, covering skills, track record,...
A step-by-step build of a Subfinder, httpx and Nuclei recon pipeline — install, script, filter the noise, and...
Notes from the front lines of bug hunting.
