Server-side request forgery (SSRF) is a vulnerability that lets an attacker make a server send requests to destinations of the attacker’s choice, including internal systems that are not reachable from the internet.
How SSRF works
Many applications fetch resources by URL: they generate link previews, import images, call webhooks or convert web pages to PDF. If the server does not restrict where it may connect, an attacker supplies an address such as http://localhost/admin, an internal IP address or the cloud metadata endpoint 169.254.169.254. The request comes from the trusted server, so firewalls let it through and internal services treat it as legitimate. The weakness is catalogued as CWE-918.
Why SSRF matters
- Cloud credential theft – metadata services in AWS, Azure and Google Cloud can return temporary access keys. In the 2019 Capital One breach, an SSRF flaw was used to obtain such keys and steal data of more than 100 million customers.
- Access to internal services – admin panels, databases, Kubernetes APIs and other systems behind the perimeter.
- Escalation – combined with other bugs, SSRF can lead to remote code execution; the ProxyLogon attack chain against Microsoft Exchange began with an SSRF flaw.
SSRF entered the OWASP Top 10 as a separate category in 2021. It effectively turns the vulnerable server into a proxy and dramatically widens the attack surface available to the attacker.
How to prevent SSRF
- Allow outgoing requests only to an allowlist of domains and protocols; do not rely on blocklists alone.
- Resolve and validate the destination IP address and block private, loopback and link-local ranges, including after redirects.
- Use IMDSv2 in AWS and equivalent protections in other clouds.
- Isolate URL-fetching components in a separate network segment with strict egress rules.
As with other vulnerabilities in web applications, regular testing helps; unlike man-in-the-middle attacks, SSRF needs no network position – only a vulnerable feature.
