SSRF - Server-Side Request Forgery

What is SSRF?

SSRF (Server-Side Request Forgery) is a vulnerability in web applications. An attacker makes the server send HTTP requests to addresses they pick themselves. The application fetches an image through a user-supplied URL, for example, and that URL is not validated enough. The result is that the attacker decides where the server sends requests.

OWASP puts it concisely: “SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL.” In MITRE terms this is CWE-918. Since 2021 SSRF is a category in its own right, A10, in the OWASP Top 10.

That URL can call anything. Often an internal system the attacker normally cannot reach. Sometimes a cloud metadata endpoint that hands over credentials. Sometimes an external service the attacker wants to abuse from your IP address. The core stays the same. The server visits a URL it should not have visited.

How does SSRF work?

Say an application offers a feature where an avatar image can be supplied by URL:

# Normal use
curl -X POST https://app.example.com/api/profile/avatar \
  -H "Authorization: Bearer ..." \
  --data '{"image_url": "https://example.com/photo.jpg"}'

The server fetches that URL and processes the response. An attacker now replaces the value of image_url:

# SSRF: server fetches a URL chosen by the attacker
curl -X POST https://app.example.com/api/profile/avatar \
  -H "Authorization: Bearer ..." \
  --data '{"image_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'

From its own position the server sends a GET request to the AWS metadata endpoint, with the rights and the network position of that server. The response comes back through the application, often in a response body or error message.

SSRF comes in two main forms. With a regular SSRF the attacker gets the response of the request straight back. With a blind SSRF that response is not visible. The attacker only knows that the request ran. A blind SSRF is confirmed through an out-of-band callback. The attacker makes the server send a request to a logging domain of their own, for example through Burp Collaborator. If that request comes in, the vulnerability is proven.

What can an attacker do with SSRF?

The impact varies strongly per environment:

• Access to internal systems. Admin panels, monitoring dashboards and unauthenticated Redis or Elasticsearch instances are unreachable from the internet. Through the vulnerable application they suddenly become reachable.
• Capturing cloud credentials. AWS, Azure and Google Cloud offer an instance metadata service (AWS on 169.254.169.254, GCP on metadata.google.internal) that is only reachable from the VM itself. A working SSRF in a cloud application can yield valid IAM credentials, access tokens or service-account keys through this endpoint. The Capital One breach in 2019 (over 100 million customer records) ran along this exact pattern.
• Protocol abuse. Besides http://, some HTTP libraries also accept file:// (read files on the server), gopher:// (send raw TCP payloads, the classic Redis RCE vector) or dict:// (interact with dict servers). These schemes give a wider attack surface than HTTP alone.
• Abuse of your server’s IP address. An attacker makes the application send large numbers of requests to external services (Google, GitHub, email providers). Your server’s IP then lands on a blacklist, after which legitimate functions break: updates stall, dependency installs fail, transactional email gets rejected. SSRF does not have to leak data to be disruptive to the business.

SSRF in a pentest

During a web application pentest we systematically walk through every place where a URL is accepted as input. The obvious candidates are webhook configuration and avatar uploads. There are also less obvious places: import features from external URLs, OAuth redirect callbacks, PDF or HTML export, RSS and feed readers, and backend integrations with third parties.

Per candidate we try a fixed set of payloads: internal IP ranges, localhost, cloud metadata endpoints, an out-of-band server of our own to confirm blind SSRF, and non-HTTP schemes to bypass filters. Does the server respond with content, an error message or timing differences that point to a request having run? Then we demonstrate which internal systems and data are reachable through that path. We show a working chain from SSRF to cloud credentials in action, not just in theory.

How do you prevent SSRF?

OWASP’s first piece of advice is clear. Use a positive allowlist, not a denylist. An allowlist means the application knows a fixed set of allowed URL destinations and refuses everything else.

• Allow only URLs from a predefined allowlist of hostnames your application actually needs. A blocklist on IP ranges almost always falls short. Attackers get around it with DNS-rebinding, IP-encoding variants (decimal, octal, hex) or redirect chains.
• Resolve the hostname yourself in your application code. Refuse the request if DNS resolution yields a private IP range (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16). Validation belongs on the IP address after DNS resolution, not on the hostname string.
• Restrict URL schemes to https:// (and http:// only if strictly needed). Do not allow file://, gopher:// and dict://. These are never used for legitimate web fetches.
• Turn off HTTP redirects, or follow them only after revalidating with the same rules. A large share of SSRF findings sit precisely in the redirect-follow logic. The original URL is legitimate, but the redirect points to localhost.
• Is the application running in AWS? Enforce IMDSv2. The metadata service then first asks for a session token through a PUT request before it returns credentials. Most SSRF payloads are GET requests and do not get through that.

At the network level, egress filtering helps. Let application servers reach only the external and internal services they actually need. Logging both allowed and blocked outbound connections makes SSRF attempts detectable instead of invisible.