SSRF

Server-Side Request Forgery

Updated September 30, 20263 min read

In short

SSRF is a vulnerability where an attacker makes a server send requests to a destination of their choice, often reaching internal systems they can't access.

What is SSRF?

Server-side request forgery happens when an application fetches a URL supplied by the user, for example to download a profile picture from a link, build a link preview, or call a webhook, without restricting where that URL can point. The attacker supplies an address such as http://localhost:8080/admin or an internal IP address, and the server makes the request on their behalf. Because the request comes from inside the network, it can reach databases, admin panels, and internal APIs that are hidden from the internet.

A classic target in the cloud is the instance metadata service at http://169.254.169.254, which can hand out temporary cloud credentials to anything running on the machine, so an SSRF flaw that reaches it can lead to a full account takeover. Attackers get around naive filters with tricks such as alternative IP formats like http://2130706433, domain names that resolve to internal addresses, and redirects from an allowed site to a forbidden one. In blind SSRF, the attacker never sees the response but can still probe which internal ports are open or trigger actions.

Defenses start with an allowlist of the schemes and hosts a feature truly needs, checked after resolving the domain name to an IP address, and with blocking private, loopback, and link-local address ranges. Also disable automatic redirects or re-check each hop, send outgoing requests through a restricted proxy or network segment, and require session tokens for cloud metadata, as newer metadata service versions do. It is like a receptionist who will fetch any file in the building for a caller who names a room: without a list of allowed rooms, a stranger on the phone can get documents from the locked archive.

SSRF is often confused with CSRF because the names are so similar. In CSRF, the attacker tricks a user's browser into sending a request to a site where the user is signed in; in SSRF, the attacker tricks the server itself into sending requests, using the server's network position and permissions. SSRF was important enough to get its own category in the 2021 OWASP Top 10.

Key takeaways

SSRF makes a server send requests to destinations chosen by an attacker.
It can reach internal services, admin panels, and cloud metadata endpoints.
Naive blocklists are bypassed with alternative IP formats, DNS tricks, and redirects.
Allowlist destinations, validate resolved IP addresses, and block private ranges.
CSRF abuses a user's browser; SSRF abuses the server itself.

Example

Fetching a user-supplied URL safelyjavascript

const ALLOWED_HOSTS = new Set(["images.example-cdn.com"]);

async function fetchUserImage(rawUrl) {
  const url = new URL(rawUrl); // throws on malformed input

  // Vulnerable version: return fetch(rawUrl), which lets a user
  // request http://169.254.169.254/ or http://localhost:6379/

  if (url.protocol !== "https:" || !ALLOWED_HOSTS.has(url.hostname)) {
    throw new Error("destination not allowed");
  }
  // Refuse redirects, which could bounce the request to an internal host
  return fetch(url, { redirect: "error" });
}

Readers ask

What is the difference between SSRF and CSRF?

CSRF tricks a victim's browser into sending a forged request to a site where the victim is signed in. SSRF tricks a server into sending requests on the attacker's behalf, which lets the attacker reach systems only that server can access.

Why is SSRF dangerous in the cloud?

Cloud servers can often reach an internal metadata service that returns temporary credentials for the machine's cloud role. If an attacker can make the server request that address and read the response, they may gain access to storage, databases, and other cloud resources.

How do you prevent SSRF?

Only fetch URLs whose scheme and host are on an allowlist, check the resolved IP address against private and internal ranges, and don't follow redirects blindly. Network-level controls, such as blocking outbound traffic from the server to internal subnets, add a second layer.