Server-side request forgery (SSRF) tricks a server into making requests on an attacker’s behalf, often to internal systems the attacker cannot reach directly. It can expose internal services, cloud metadata and sensitive data, and it has been behind major cloud breaches. Validated testing proves whether your applications can be abused this way.
What SSRF is
Server-side request forgery, or SSRF, is a vulnerability where an attacker can make your server send requests to places the attacker chooses. Many applications legitimately fetch things by request, an image from a URL, data from another service, and if an attacker can control where those requests go, they can turn your server into a proxy for their own purposes.
The danger comes from position. Your server sits inside your network, with access to internal systems and services that an outside attacker cannot reach directly. SSRF lets the attacker borrow that position, making requests from inside your environment by tricking your server into making them. It is a way to reach the unreachable.
How attackers exploit it
Exploiting SSRF typically means finding a feature where the application makes a request based on input the attacker can influence, then changing that input to point somewhere else. Instead of the intended external resource, the attacker directs the server to internal addresses, internal services, or other targets they could not otherwise reach.
Once they can make the server issue requests on their behalf, attackers probe the internal environment: mapping internal services, reaching administrative interfaces, and pulling data from systems that assumed any request from the server was trustworthy. The application becomes an unwitting tunnel into the network behind it.
Why it is dangerous in cloud environments
SSRF became especially notorious in cloud environments, and for a specific reason. Many cloud platforms expose an internal metadata service that instances can query to retrieve configuration and, in some setups, credentials. That service is reachable from the instance itself, which is normally fine, until SSRF lets an attacker make the instance query it on their behalf.
When that happens, an attacker can potentially retrieve cloud credentials or sensitive configuration through the server, turning a web application flaw into a foothold in your cloud environment. This is why SSRF is treated with particular seriousness in cloud contexts: the internal metadata service is a high-value target that SSRF can unlock.
Real-world impact
SSRF is not a theoretical concern. It has played a central role in major cloud breaches, where an SSRF flaw in a web application was used to reach a cloud metadata service, obtain credentials, and access large volumes of sensitive data. Those incidents elevated SSRF from a lesser-known web flaw to a recognised, high-priority risk, and drove changes in how cloud platforms protect their metadata services.
The lesson from those breaches is that a single SSRF flaw, in the wrong place, can be the pivot point of a serious compromise. It is rarely the whole attack, but it is often the crucial link that connects a web flaw to a cloud breach.
How to prevent it
Preventing SSRF combines application-level and network-level defences. At the application level, validate and restrict the input that determines where the server makes requests, so an attacker cannot redirect it freely, and limit what the server is allowed to request. At the network level, restrict the internal resources the server can reach, so that even if SSRF occurs, the server cannot access sensitive internal services or metadata endpoints.
In cloud environments specifically, using the protections cloud providers offer for their metadata services closes the most dangerous SSRF path. Defence in depth matters here: application controls reduce the chance of SSRF, and network controls limit the damage if it happens anyway.
Why validation matters over scanning alone
SSRF can be subtle, depending on how an application handles requests, and whether a given flaw is genuinely exploitable, and what it can reach, depends on your specific environment. A scanner may flag a potential SSRF, but confirming whether an attacker could actually exploit it to reach internal services or cloud metadata requires testing it.
Validated testing safely attempts the exploitation, proving whether your application can be abused this way and what an attacker could reach through it. That difference, between a flagged possibility and a confirmed, demonstrated risk, is what tells you how urgent it is. And because applications change, that validation needs to be ongoing.
To confirm whether your applications are exploitable via SSRF, explore our web application security capability, or read how continuous service validation keeps that assurance current.
For the technical detail, see the OWASP SSRF reference.
Frequently asked questions
What is server-side request forgery?
SSRF is a vulnerability where an attacker tricks your server into making requests to places they choose, often internal systems the attacker cannot reach directly. It turns your server into a proxy for the attacker, borrowing its trusted position inside your network.
Why is SSRF dangerous?
Because the server sits inside your network with access to internal services an outside attacker cannot reach. SSRF lets the attacker make requests from that trusted position, reaching internal services, administrative interfaces and sensitive data through the server.
Why is SSRF a cloud risk?
Many cloud platforms expose an internal metadata service that instances can query, sometimes for credentials. SSRF can let an attacker make an instance query that service on their behalf, potentially retrieving cloud credentials, which has featured in major cloud breaches.
How do you prevent SSRF?
Validate and restrict the input that controls where the server makes requests, limit what the server can request, and use network controls to restrict the internal resources it can reach. In cloud environments, use the provider’s metadata protections, and validate the app is not exploitable.
