What Is SSRF? Server-Side Request Forgery Explained

Server-side request forgery (SSRF) is a vulnerability where an attacker manipulates a server into making HTTP requests to destinations the attacker chooses — often internal systems that aren’t supposed to be reachable from outside the network at all. Any feature where a server fetches a URL on a user’s behalf — loading a profile picture from a link, fetching a webhook target, generating a PDF preview of a page — is a potential SSRF entry point if that URL isn’t tightly restricted.

How the attack works

Picture a feature that lets users submit an image URL, and the server fetches that image to resize and store it. The intended use is fetching public images. But the server is just making an HTTP request to whatever URL it’s given — and the attacker controls that URL.

Instead of a public image link, the attacker supplies a URL pointing at an internal address: an admin panel on the private network, an internal API with no authentication because it “only” faces internal traffic, or a cloud provider’s instance metadata service, which on most cloud platforms is reachable at a fixed internal address and can hand back temporary credentials to whatever asks. The server, sitting inside the trusted network perimeter, makes the request exactly as instructed. It fetches the response, and depending on the feature, might even hand that response back to the attacker — turning an image-loading feature into a way to read internal systems the attacker could never reach directly.

Why it’s dangerous specifically because of where the server sits

The core danger of SSRF isn’t the request itself — it’s that the server making it is inside the trust boundary. Internal services are often left lightly protected specifically because the assumption is that only trusted internal callers can reach them. SSRF breaks that assumption by turning an internet-facing server into a proxy the attacker controls, borrowing its network position and, in cloud environments, sometimes its identity and credentials too.

SSRF vs CSRF

The names are easy to confuse, but the two attacks work in opposite directions:

	SSRF	CSRF
Who is tricked	The server	The victim’s browser
Request originates from	The server itself	The victim’s authenticated browser session
Target of the forged request	Internal systems, cloud metadata, other services	The application the victim is already logged into
Core defense	Validate and restrict outbound URLs	CSRF tokens, SameSite cookies

CSRF abuses a logged-in user’s browser to make requests they didn’t intend. SSRF abuses a server’s own outbound requests to reach places the attacker couldn’t reach directly. They share the word “forgery” but attack different trust relationships.

Blind vs full-response SSRF

Not every SSRF exposes its results directly. In a full-response SSRF, the application returns the fetched content back to the attacker — the image-resizing example above is this case, since the attacker can see whatever the server retrieved. In a blind SSRF, the application makes the internal request but never shows the attacker the response body — say, a webhook feature that just returns success or failure. Blind SSRF is still dangerous: an attacker can use timing differences, error messages, or the mere fact that a request succeeded or failed to infer which internal hosts and ports exist, effectively using the server as a scanner even without seeing any response content directly.

Common mitigations

• Allowlist destinations rather than trying to blocklist them — block lists are easy to bypass with redirects, alternate IP encodings, or DNS tricks; an allowlist of known-good hosts is far harder to route around.
• Block requests to internal/private IP ranges and link-local addresses at the network layer, not just in application code, so a bypassed check still can’t reach internal targets.
• Disable or carefully validate redirects — a URL that passes validation can still redirect to an internal address after the check has already run.
• Restrict allowed URL schemes to http/https only, since schemes like file:// or gopher:// can be abused to reach local files or other protocols entirely.
• Segment the network so that even a successful SSRF from a public-facing server can’t reach sensitive internal systems — this is the practical expression of zero trust thinking, where no internal caller is trusted by default just because of its network position.
• Put a reverse proxy or WAF in front of the request path where possible, giving you a layer to enforce URL restrictions consistently rather than relying on every feature implementing its own checks correctly.

The takeaway

SSRF turns any server-side feature that fetches a user-supplied URL into a potential bridge from the public internet into a network’s internal systems. The fix is to treat every outbound URL a server fetches on someone else’s behalf as untrusted input — allowlist destinations, block internal IP ranges at the network layer, and don’t let redirects or scheme tricks slip past validation. It’s a different attack from CORS misconfiguration or CSRF, but it belongs in the same category of problems: trust boundaries that looked solid until a feature quietly gave an attacker a way to make requests on the server’s behalf.