SSRF lets an attacker make a server send requests to a destination of their choosing. It arises when an app takes a user-supplied URL and fetches it server-side without restricting where it can connect - so instead of reaching only intended external services, the attacker points it at internal systems, other services on the same network, or special internal addresses. Because the request comes from the trusted server, it reaches places an outside attacker can't - effectively using the server as a proxy into the internal environment. In the cloud it's lethal: SSRF can query the instance metadata service to steal the server's temporary role credentials, turning one web bug into a cloud-account compromise - the mechanism behind several major breaches. Fixes: strict allowlist of destinations, careful URL validation, network segmentation, the hardened session-based metadata service (IMDSv2), and least-privilege instance roles. Deep-dive on the cloud angle: SSRF, IMDSv2 & STS.
// 01 What SSRF is
Server-side request forgery (SSRF) is a vulnerability in which an attacker can make a server send HTTP (or other) requests to a destination of the attacker's choosing. It arises when an application takes a user-supplied value - such as a URL - and uses it to fetch a resource on the server side without properly restricting where it can connect. Think of features like “import from URL,” webhooks, URL previews, PDF generators, or image fetchers. Instead of the server only reaching the intended external services, the attacker can point it at internal systems, other services on the same network, or special internal addresses. Because the request originates from the server, it's trusted and can reach places an outside attacker cannot - effectively using the server as a proxy into the internal environment. That's what makes SSRF such a powerful way to bypass network boundaries and reach otherwise-protected resources, and why it earned its own place in the OWASP Top 10.
// 02 Why the cloud makes SSRF lethal
SSRF is especially dangerous in the cloud because cloud platforms expose an internal metadata service - reachable only from within the instance at a special internal address - that hands out configuration and, in some cases, temporary credentials for the instance's assigned role. If an attacker can use SSRF to make a vulnerable server request that internal metadata endpoint, they may retrieve those credentials and then use them to access cloud resources with the permissions the server has. That turns a single web vulnerability into a broad compromise of the cloud account - which is exactly why SSRF has been behind several major cloud breaches. In response, cloud providers introduced stronger metadata-service protections that require a deliberate handshake (a session token) to access the metadata, reducing the risk that a naive SSRF can steal credentials. We cover that mechanism - and the STS credential path - in depth in SSRF, IMDSv2 & STS: cloud privilege escalation, and it's a core check in every cloud penetration test.
// 03 What an attacker can do with SSRF
Reach internal services
Scan and reach internal services and ports not exposed to the internet, and internal-only apps and admin interfaces.
Steal cloud credentials
Query the instance metadata service to obtain temporary role credentials - the cloud escalation path.
Pull internal data
Retrieve data from internal APIs, and via certain URL schemes reach databases or internal file systems.
Map the network (blind)
Even blind SSRF - no visible response - can map the internal network or trigger actions.
In short, SSRF lets an attacker reach places they can't reach directly. Depending on what the server can talk to, it can be chained with other weaknesses - reaching back-end systems, and in some cases leading to remote code execution. The severity depends entirely on what the vulnerable server is allowed to connect to internally, which is why segmentation matters as much as input handling.
// 04 How to prevent SSRF
The strongest defence is to restrict where the server is allowed to make requests: use a strict allowlist of permitted destinations rather than trying to blocklist bad ones (blocklists are trivially bypassed with alternate encodings, DNS tricks and redirects), and validate and resolve user-supplied URLs carefully so they can't be manipulated to point at internal addresses. Network controls help just as much: systems that make outbound requests should be segmented so they cannot reach sensitive internal services or the cloud metadata endpoint unless genuinely required - the same segmentation discipline that limits any breach. In the cloud specifically, enforce the hardened, session-based metadata service (IMDSv2) and give instances least-privilege roles so even stolen credentials are limited. Finally: disable unnecessary URL schemes, don't follow redirects blindly, and treat any server-side fetch of a user-controlled URL as dangerous by default. In a web app or cloud test we actively probe every URL-taking feature for exactly these paths.
// 05 Frequently asked questions
What is server-side request forgery?
A vulnerability where an attacker can make a server send HTTP or other requests to a destination of their choosing. It arises when an application takes a user-supplied URL and fetches it server-side without restricting where it can connect. Instead of reaching only intended external services, the attacker points it at internal systems, other services on the same network, or special internal addresses. Because the request comes from the trusted server, it reaches places an outside attacker cannot - using the server as a proxy into the internal environment.
Why is SSRF so dangerous in the cloud?
Cloud platforms expose an internal metadata service - reachable only from within the instance - that can hand out configuration and temporary credentials for the instance's role. If an attacker uses SSRF to make a vulnerable server request that metadata endpoint, they may retrieve those credentials and access cloud resources with the server's permissions, turning one web bug into a broad cloud-account compromise. That's why SSRF has caused several major breaches, and why providers introduced stronger metadata protections requiring a deliberate session handshake.
What can an attacker do with SSRF?
Make the server reach places they can't reach directly: scan and reach internal services and ports not exposed to the internet, access internal-only apps and admin interfaces, retrieve data from internal APIs, and in the cloud query the metadata service for credentials. It can be chained to reach databases or internal file systems via certain URL schemes, and sometimes leads to remote code execution. Even blind SSRF, where the response isn't visible, can map the internal network or trigger actions. Severity depends on what the server can connect to internally.
How do you prevent SSRF?
Restrict where the server can make requests: use a strict allowlist of destinations rather than a blocklist, and validate and resolve user-supplied URLs carefully so they can't point at internal addresses. Segment the systems that make outbound requests so they can't reach sensitive internal services or the cloud metadata endpoint unless required. In the cloud, enforce the hardened session-based metadata service and give instances least-privilege roles. Disable unnecessary URL schemes, don't follow redirects blindly, and treat any server-side fetch of a user-controlled URL as dangerous.
// 06 Related reading
- SSRF, IMDSv2 & STS — the cloud credential-theft path in depth.
- Cloud penetration testing and internal vs external testing.
- OWASP Top 10 in real engagements and command injection.