What Is Server-Side Request Forgery (SSRF)?

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a server into making an HTTP request to a destination the attacker chooses, rather than the one the application intended. Because the request originates from the server itself, it can reach internal systems, cloud metadata services, and other resources that aren't accessible directly from the outside internet.

Many web applications fetch data from a URL on the server's behalf — generating a preview of a link a user pastes, fetching an image from a remote address, or calling a webhook. SSRF happens when that URL isn't properly validated, letting an attacker supply a destination of their own choosing instead of a legitimate one.

The reason this matters more than it might initially sound is the server's position on the network. A server making a request from inside a private cloud environment or internal network can typically reach things the public internet can't — internal admin panels, databases, other microservices, and cloud provider metadata endpoints that hold credentials and configuration data. SSRF turns the server into a proxy an attacker can direct toward all of that.

This is also what makes SSRF distinct from CSRF (Cross-Site Request Forgery), despite the similar name. CSRF tricks a victim's browser into making an unwanted request using the victim's own authenticated session. SSRF tricks the server itself into making the unwanted request — no victim browser or session involved at all.

Use Cases (Where SSRF Occurs)

1. URL preview or "fetch this link" features that request the destination server-side before displaying a result to the user
2. Image or file import functionality that pulls a resource from a user-supplied URL
3. Webhook configuration where a server sends requests to a URL the user specifies
4. PDF generators or document converters that fetch external resources (images, stylesheets) as part of rendering
5. Cloud metadata service access — a well-known SSRF target is the cloud provider's internal metadata endpoint (e.g., 169.254.169.254 on AWS), which can expose temporary credentials and configuration data if reachable

Best Practices

• Validate and allowlist destination URLs against a known-safe set, rather than trying to blocklist known-bad ones
• Block requests to internal IP ranges, loopback addresses, and cloud metadata endpoints at the network level, not just in application code
• Disable unnecessary URL schemes (like file:// or gopher://) that can be abused beyond simple HTTP requests
• Use IMDSv2 (or equivalent) on cloud infrastructure, which requires a session token and is significantly harder to exploit via SSRF than older metadata service versions
• Apply least-privilege network segmentation, so that even if SSRF occurs, the server making the request has limited reach into sensitive internal systems

How It Works: Step-by-Step

1. Identify a server-side fetch feature. The attacker finds functionality where the application makes a request to a URL — directly or indirectly supplied by the user.
2. Supply a malicious destination. Instead of a legitimate external URL, the attacker provides an internal address, a cloud metadata endpoint, or another restricted target.
3. Server makes the request. The vulnerable server, trusting the input, sends the request to the attacker-chosen destination on the attacker's behalf.
4. Response handling reveals data (or not). In a "basic" SSRF, the response is returned to the attacker, potentially exposing internal data. In a "blind" SSRF, no response is visible, but the attacker can still infer results through timing, side effects, or out-of-band signals.
5. Escalation. Depending on what's reachable, SSRF can lead to internal service enumeration, credential theft from metadata endpoints, or — in more severe cases — remote code execution if it reaches an internal service that itself has exploitable vulnerabilities.

Conclusion

SSRF is a reminder that a server's own network position is part of its attack surface — a request the server makes on its own behalf can reach places an external attacker never could directly. That's what makes proper URL validation, network segmentation, and metadata service protections non-optional for any application that fetches user-influenced URLs server-side, rather than a nice-to-have hardening step.

FAQ