SSRF: Server-Side Request Forgery Explained

What SSRF Actually Is

Server-Side Request Forgery happens when an application feature makes an outbound HTTP (or other network) request to a destination that's influenced, directly or indirectly, by user input, without properly restricting where that request is allowed to go. Common legitimate features that fetch a user-supplied URL — generating a preview thumbnail of a linked page, validating a webhook endpoint, fetching an avatar image from a URL, processing a PDF export request — all involve exactly this pattern, and each one is a potential SSRF vector if the destination isn't properly restricted.

The core danger is that the request originates from the server itself, not from the attacker's own machine, meaning it can reach destinations the attacker could never access directly — internal network services behind a firewall, admin interfaces bound only to internal IP ranges, or cloud infrastructure metadata endpoints that are only reachable from within the cloud environment itself.

Why Cloud Infrastructure Made SSRF Dramatically More Dangerous

Most major cloud providers expose an internal metadata service, reachable only from within a running instance at a fixed, well-known internal address, that provides configuration details about that specific server — including, in many default configurations, temporary security credentials that grant whatever permissions the instance's assigned role has. This metadata service was never meant to be reachable from outside the instance itself, but an SSRF vulnerability that lets an attacker direct the server to request its own metadata endpoint can extract those credentials directly.

This specific attack pattern — SSRF against cloud metadata services — has been the root cause of several major, publicly documented breaches, precisely because the credentials obtained this way often grant far broader access than the original vulnerable application itself needed, letting an attacker pivot well beyond the initially compromised feature into other cloud resources entirely. It's a large part of why SSRF's severity rating increased significantly industry-wide once cloud infrastructure became the default deployment environment for most web applications.

Internal Network Access: The Other Major SSRF Risk

Beyond cloud metadata, SSRF frequently provides a path into internal network segments that have no business being reachable from the public internet at all — internal admin panels, databases without external-facing authentication (since they were never meant to be reached externally), or internal monitoring and orchestration tools. An organization's perimeter firewall, designed to keep external attackers out, provides no protection here at all, since the malicious request originates from inside that perimeter, issued by a server the firewall already trusts.

This is why SSRF is sometimes described as a firewall-bypass technique as much as a standalone vulnerability — the network segmentation an organization relies on for defense-in-depth becomes irrelevant the moment a trusted internal server can be tricked into making requests on an external attacker's behalf.

Blind SSRF vs Response-Based SSRF

Blind SSRF, where the vulnerable feature doesn't return the fetched content back to the attacker, is often mistakenly treated as lower-severity, but it can still confirm which internal hosts and ports are reachable (effectively enabling internal network reconnaissance) and, in some cases, be chained with other techniques to achieve impact well beyond what the missing visible response might suggest.

Why URL Validation Is Harder Than It Looks

A naive SSRF defense — checking that a user-supplied URL doesn't point at an obviously internal address like localhost or a private IP range — fails against several well-documented bypass techniques. A hostname can resolve to a private IP through DNS while looking completely innocuous at validation time (DNS rebinding), an IP address can be represented in multiple valid but unusual formats that a simple string check misses (decimal, octal, or IPv6-mapped representations of the same address), and a URL that passes validation can still redirect to an internal address after the validation check has already approved it, if the fetching code follows redirects without re-validating the final destination.

This is why effective SSRF prevention requires validation at the network level, not just the string level: resolving the hostname and checking the actual resulting IP address against a strict allowlist immediately before the request is made, disabling automatic redirect following (or re-validating after each redirect), and ideally routing outbound requests from this kind of feature through a dedicated proxy that enforces destination restrictions independently of the application's own logic.

SSRF in Server-Side APIs and Microservice Architectures

SSRF risk isn't limited to obviously URL-fetching features like previews and webhooks — modern microservice architectures, where one internal service routinely calls another over HTTP based on parameters that ultimately trace back to user input, can carry the same risk in a less obvious form. If a request parameter influences which internal service endpoint gets called, and that influence isn't properly restricted, the same fundamental SSRF pattern applies even though no feature was explicitly designed as a "fetch a URL" function at all.

This makes SSRF risk assessment genuinely harder in complex, service-oriented architectures than in a simple monolithic application, since the vulnerable code path can be several service hops removed from the original user-facing input, and a security review focused only on obviously URL-shaped features can miss this less direct variant entirely.

SSRF and the Server-Side Fetching of Third-Party Content

Features that generate previews, thumbnails, or summaries of externally linked content are so consistently associated with SSRF that they deserve treatment as a distinct risk category on their own, separate from more obviously "advanced" features like webhook validators or PDF converters. The reason is simple: link previews are extremely common (social platforms, chat applications, note-taking tools, project management software all commonly include one), are often built early in a product's life before rigorous security review processes are established, and fetch genuinely arbitrary user-supplied URLs by design, which is exactly the SSRF precondition.

Teams building or maintaining a link-preview-style feature specifically benefit from treating it as security-sensitive infrastructure from the start, rather than a purely cosmetic convenience feature bolted on without the same scrutiny applied to authentication or payment-handling code — the actual technical risk it carries is genuinely comparable, even though it doesn't feel that way from a product perspective.

Real Scenarios Involving SSRF

A social media platform's link-preview feature fetches whatever URL a user pastes into a post to generate a thumbnail and title. Without destination restrictions, a malicious user submits a link pointing at the server's own cloud metadata endpoint instead of a real webpage, and the preview feature's response inadvertently displays fetched credential data back in the generated preview text.

An internal document-processing service converts a URL to a PDF on request, running inside a cloud environment. A penetration test confirms it will fetch and render internal-network-only URLs, including an internal admin dashboard with no separate authentication of its own, demonstrating a direct path from a public-facing feature into infrastructure that was never meant to be internet-reachable.

A webhook-validation feature checks that a URL is reachable before saving it as a customer's notification endpoint, and a security review finds it doesn't restrict which destinations it will attempt to reach, flagging it before launch since webhook-validation features are a consistently common, easily overlooked SSRF entry point.

An organization's cloud security audit specifically checks whether metadata service credentials are scoped to the minimum permissions each instance actually needs, treating SSRF as an assumed eventual risk and limiting the blast radius of stolen credentials rather than relying entirely on preventing SSRF from ever occurring in the first place.

Preventing SSRF

The most effective defense is a strict destination allowlist: if a feature only ever needs to fetch URLs from a known, limited set of legitimate destinations, restrict it to exactly that set rather than accepting arbitrary URLs at all. Where arbitrary user-supplied URLs are genuinely required, validate the resolved IP address (not just the hostname string) immediately before making the request, explicitly block private and reserved IP ranges (including the specific cloud metadata address ranges), and disable or carefully control automatic redirect following so a validated destination can't silently become an unvalidated one after the check has already passed.

On the infrastructure side, ensuring cloud metadata endpoints require an additional authentication step (a protection many cloud providers now enable by default on newer instances specifically because of how common metadata-targeting SSRF became) adds a meaningful layer of protection that doesn't depend on the application's own input validation being perfect. Network segmentation that genuinely isolates internal services from servers that process external, user-influenced requests limits how much SSRF alone can actually reach, even when a vulnerability does exist somewhere in the request-handling code.

FAQ