SSRF Explained
Server-side request forgery is a vulnerability where an application makes an HTTP request to a destination an attacker controls. Because the request originates from the server, it reaches internal systems the attacker cannot reach directly. In cloud environments SSRF frequently escalates to credential theft through the instance metadata service, which is what turns it from a medium finding into a critical one.
SSRF is worth understanding properly because its severity is almost entirely environmental. The same bug is minor in one architecture and catastrophic in another.
Where it comes from
Any feature where the application fetches a URL on your behalf:
- URL preview and link unfurling
- Webhook configuration
- Image or document import from a URL
- PDF generation from a page
- File upload by URL
- XML parsers processing external entities
- Integration and callback settings
Look for any parameter containing a URL, hostname or IP. Also look for the ones that do not obviously contain a URL but accept one, such as a filename field that also handles remote paths.
Confirming it
Point the parameter at a host you control and watch for the callback. Note the source IP, since that tells you whether the request came from the application server or an egress proxy, and note the User-Agent, which often identifies the fetching library and therefore the bypasses that will work.
If there is no visible response, you may still have blind SSRF. Out-of-band confirmation is the only reliable detection there, and blind SSRF is frequently still exploitable.
Bypasses that still work
Most applications block obvious internal addresses. The blocks are usually string-based and usually insufficient.
| Technique | Why it works |
|---|---|
| Alternative IP encodings | Decimal, octal and hexadecimal forms of the same address defeat string matching |
| DNS pointing to internal IPs | Your domain resolves to an internal address, passing hostname allowlists |
| Redirect chains | An allowed external host returns a 302 to an internal one |
| DNS rebinding | Resolution changes between the validation check and the actual request |
| Alternative schemes | file, gopher, dict where the fetching library supports them |
| IPv6 and mapped addresses | Filters written for IPv4 miss the equivalents |
| Credential syntax in the URL | Parser confusion between the userinfo component and the host |
The last one is the same class of parsing confusion that makes malformed URLs dangerous generally.
Escalation paths
Cloud metadata
The highest-impact escalation. Cloud providers expose an instance metadata service on a link-local address, reachable only from the instance itself. Where it is accessible and not protected by session-based access controls, SSRF can retrieve instance credentials, which converts a web bug into cloud account access.
This is why SSRF severity is environmental. The identical vulnerability on a hardened instance with metadata protections enabled is a fraction of the risk.
Internal service access
Internal admin panels, dashboards, databases with HTTP interfaces, container orchestration APIs and service meshes. Anything that trusts the network position rather than authenticating the caller.
Port scanning
Response timing and error differences map the internal network. Slow, noisy, and effective.
What actually defends against it
- Allowlist destinations. Not a blocklist. Blocklists lose to the table above every time.
- Resolve then validate then connect. Validate the resolved IP, not the hostname string, and prevent re-resolution between check and request.
- Block internal ranges at the network layer. Egress rules on the host, not logic in the application.
- Protect the metadata service. Enforce the session-based access controls your cloud provider offers.
- Disable unnecessary schemes. HTTP and HTTPS only.
- Do not follow redirects blindly. Or revalidate every hop.
- Use a dedicated egress proxy. Fetching from a network position with no internal access removes the entire class.
Reporting it well
SSRF gets downgraded when the report shows only a callback to an attacker host. Demonstrate what it reached: an internal service, a metadata response with credentials redacted, a mapped internal range. Impact is the argument, not the callback.
Structure in how to write a VAPT report.
Why it matters more now
SSRF has become more valuable as architecture moved to cloud and microservices, because there is simply more behind the perimeter to reach. It also appears in AI application testing, where a model with browsing capability can be steered into fetching internal URLs through prompt injection, which is SSRF with the model as the confused deputy.
Practise this
Find SSRF manually and then work the escalation, because the escalation is where the severity is decided and where scanners stop.
Hacklido is free and covers web and API challenges. The TCVE VAPT program covers SSRF and cloud escalation paths with live targets.
Frequently asked questions
What is SSRF in simple terms?
A vulnerability where an application can be made to send HTTP requests to a destination the attacker chooses. Because the request comes from the server, it reaches internal systems the attacker cannot reach directly.
Why is SSRF considered critical?
Because in cloud environments it frequently escalates to instance credential theft through the metadata service, turning a web application bug into cloud account access.
How do I test for SSRF?
Point any URL-accepting parameter at a host you control and watch for the callback. If there is no visible response, use out-of-band detection, since blind SSRF is still exploitable.
Does blocking internal IP addresses prevent SSRF?
No. String-based blocklists are defeated by alternative IP encodings, DNS records pointing at internal addresses, redirect chains and DNS rebinding. Allowlisting destinations is the reliable approach.
Is SSRF relevant to AI applications?
Yes. A model with browsing or tool access can be steered into fetching internal URLs through prompt injection, which is the same confused deputy problem.
See the Cloud Security syllabus
Live instructor led training, hands on labs and a verifiable certificate. Or start free on Hacklido before paying anyone.
See the Cloud Security syllabus