What Is Server-Side Request Forgery (SSRF)

SSRF is a vulnerability where an attacker makes a server issue an HTTP request to a destination of the attacker's choosing. Because the request originates inside the server's network, it can reach internal services, cloud metadata, and loopback addresses that the attacker could never reach directly. The fix is to validate the destination, not the URL string.

Server-Side Request Forgery is a vulnerability in which an application takes a URL (or a hostname, or an address) from user input and fetches it on the server. If the application does not check where that URL points, an attacker can supply an internal destination and make the server request it on their behalf.

Why the origin of the request matters

The danger is not the fetch itself; it is who is making it. A request from the public internet cannot reach a database on 10.0.0.5, an admin panel on localhost, or a cloud metadata service on 169.254.169.254. A request from the application server usually can, because that server sits inside the trust boundary. (server-side request forgery) lets an attacker borrow the server's network position.

Where it shows up

Any feature that fetches a user-supplied URL is a candidate: webhook senders, link-preview and unfurl services, image and document proxies, (Portable Document Format) or screenshot generators, RSS and import tools, and "check this URL" health probes. All of them accept an address and make a request, which is exactly the primitive SSRF abuses.

What an attacker gains

Reaching internal-only services can expose admin interfaces, unauthenticated internal APIs, and management ports. The highest-value target is often the cloud instance metadata endpoint, which can hand back temporary credentials for the server's role. SSRF is also used for internal port scanning, since the timing and errors of the fetch reveal which internal hosts and ports are alive.

The shape of the fix

Because the same address can be written many ways, filtering the URL text is not enough. The reliable approach is to resolve the destination and classify the resulting IP against known-internal ranges, allow only the addresses you intend to reach, and restrict the scheme to http and https. That classification of a destination is exactly what the SSRF URL classifier performs, locally and without ever issuing the request.

The trust boundary the request crosses

SSRF matters because of where the request comes from, not what it fetches. The server is inside, and the internal network usually treats it as such: no authentication on the admin endpoint, a database that trusts its subnet, a metadata service that answers anything on the local link.

That is why the impact is so variable and so often underestimated in triage. The same flaw is a curiosity on a flat network with authenticated services, and a full compromise on a network that outsourced its access control to topology.

Rate the flaw by what your internal network assumes about internal callers, not by what the vulnerable endpoint appears to do. The endpoint is the door; the assumptions behind it are the reason the door matters.