Server-side request forgery happens when your application fetches a URL that a user controls, and an attacker points it somewhere it was never meant to go. The request comes from inside your network, so firewalls do not stop it and logs show your own server making the call. OWASP added it to the Top 10 in 2021 as A10 after a community survey put it near the front of developer concerns.
Where SSRF turns up in real applications
SSRF lives in any feature that takes a link and does something useful with it. Think of the profile page that imports an avatar from a URL, the invoice tool that renders a web page to PDF, the integration screen that validates a webhook address before saving it, or the document preview that fetches a file from wherever the user says. Each of those makes an outbound request with your server’s network position. Cloud environments raise the stakes. The metadata service at 169.254.169.254 hands out temporary credentials to anything that asks from the instance, which is how the 2019 Capital One breach turned one web flaw into more than a hundred million customer records.
What a tester actually tries
A tester starts by finding every input that accepts a URL, then watches where the server goes. The first probe is usually an address controlled by the tester, because a request arriving at that host proves the vulnerability even when the application shows nothing on screen. Blind SSRF behaves exactly like that: no output, no error, just a DNS lookup landing somewhere it should not. After that the work moves to bypasses. Decimal and octal representations of internal addresses, redirects that start on an allowed domain and land on an internal one, and DNS records that resolve to a public address on the first lookup and a private one on the second all get tried, because blocklists tend to catch only the obvious cases.
“Developers usually patch the exact payload we showed them and leave the pattern in place. If the fix is a list of banned strings, we will be back through it in an afternoon with a redirect. Build an allowlist of the hosts your feature is genuinely meant to reach, then give that outbound traffic its own egress path so a mistake in the code does not become a route into your subnet.”
William Fieldhouse, Director, Aardwolf Security Ltd
What good remediation looks like
You should fix SSRF at the network layer as well as in the code, because either one on its own tends to fail. In the application, resolve the hostname first and check the resulting IP address against an allowlist, then make the request without following redirects. On the infrastructure side, put the component that makes outbound calls in a subnet with a restricted egress rule, and require IMDSv2 on every instance in AWS so a stolen request cannot read credentials without a session token. Teams running a web application penetration test alongside a cloud review find these two halves quickly, because the tester can see both the parameter and the role it reaches.
Why cloud environments make it worse
In a cloud estate, an internal request often carries authority that an external one never would. Internal APIs sit behind a service mesh and trust anything inside the perimeter. Admin panels bind to localhost and skip authentication because nobody outside can reach them. Kubernetes API servers answer requests from pods. That is why SSRF findings from AWS penetration testing usually escalate further than the same flaw on a single server in a rack. Assume any service you did not expect to be reachable will be reachable, and put authentication in front of it anyway.
Frequently asked questions about SSRF
These are the questions development teams ask once an SSRF finding lands in a report.
Is SSRF only a problem for large applications?
No. A small marketing site with a link preview feature has the same exposure as a banking portal, and often less monitoring. What differs is what sits behind the server, not the size of the application.
Will a web application firewall stop it?
Partly, and not reliably. A firewall can block obvious internal addresses in a parameter, but it cannot follow a redirect chain or resolve a hostname the way your server will. Treat it as noise reduction rather than a fix.
