What is SSRF (Server-Side Request Forgery)? How it works and how to prevent it

Server-Side Request Forgery (SSRF) is a security vulnerability that lets an attacker make a vulnerable server send requests to internal or external systems, or to the server itself. The attack works when a server has functionality that fetches a URL supplied or modified by the user — such as importing from a URL, downloading an avatar image, or sending a webhook. By carefully choosing that URL, the attacker can make the server read resources that are not exposed to the public internet.

SSRF is one of the most serious web vulnerabilities. OWASP lists it among the most critical API security risks, and it is recognized as one of the most serious software weaknesses. In severe cases an SSRF can compromise a cloud environment, exploit internal hosts, leak sensitive information, or turn the server into a proxy for further attacks.

This guide explains how SSRF attacks work, what an attacker can reach, and the defenses that reliably prevent them.

How SSRF works

The vulnerable application exposes a feature that reads data from a URL — for example a URL the user submits and the code on the server fetches. Instead of a public website, the attacker supplies a URL pointing at internal resources. The server-side code then picks up the crafted URL and tries to read from it.

Common examples of features attackers abuse:

• Image download — a user enters the URL of an avatar image and the application downloads and uses it.
• Custom webhooks — a user specifies a webhook handler or callback URL that the application calls.
• PDF or document generators — a feature that renders a page from a user-supplied URL.
• URL importers — tools that fetch a link's content to embed or preview it.

An attacker chooses target URLs such as:

http://169.254.169.254/        AWS, GCP and Azure instance metadata service
http://localhost/              services running on the server itself
http://10.0.0.1/               RFC 1918 private network
file:///etc/passwd             read local files if the fetcher supports file://

Because the request originates from the server, it carries the server's network privileges. The server can reach internal services — databases, administration interfaces, or other backends — that are blocked from the public internet. The security boundary that would normally protect these resources no longer protects them, because the trusted server is the one making the request.

Types of SSRF

SSRF is categorized by whether the attacker can observe the response:

Basic (non-blind) SSRF — the response is returned to the attacker. The server fetches the URL the attacker requested and sends the result back. This is the easiest form to exploit: the attacker directly reads the data from an internal service.

Blind SSRF — the response is not sent back to the attacker. The request still triggers actions on the target, but the attacker cannot directly read the output. In this case the attacker confirms the vulnerability indirectly, for example by observing timing differences, sending a request to a server they control, or triggering a side effect on the target.

What an attacker can reach with SSRF

The impact depends on what the server can access and whether any response is observable:

• Cloud instance metadata — the link-local address 169.254.169.254 is used by AWS, Google Cloud and Azure to expose instance metadata. In older AWS setups this included IAM temporary credentials. An SSRF that reaches this endpoint can leak credentials and compromise the cloud account.
• Internal services — a server often can connect to databases, admin panels, monitoring tools, or microservices on the private network. SSRF turns these reachable.
• The server itself — localhost services that run on the same machine become reachable through the server's own network stack.
• Local files — if the fetcher supports non-HTTP schemes such as file://, the attacker can read files on the server's filesystem (for example /etc/passwd).
• Server as a proxy — because requests come from the vulnerable server, SSRF can scan the internal network and conceal further attacks behind the compromised server's identity.

SSRF is not limited to HTTP. When the application performs the follow-up request, it may use other protocols and schemes such as ftp://, smb://, gopher://, data://, or dict://. In addition, an XML External Entity (XXE) vulnerability in a parser can be chained to perform SSRF by making the parser fetch an external address.

Defenses that prevent SSRF

OWASP recommends different defenses depending on whether the application only needs to reach a fixed set of trusted services, or must fetch arbitrary external URLs.

Case 1 — The application only talks to identified, trusted services

When the application's calls are limited to a well-known set of internal services, use an allowlist. The allowlist approach is stronger than a blocklist because it rejects everything by default and only permits known-good destinations.

• Validate the input — ensure the supplied value matches the expected format. If the input is a domain name or IP address, validate it is a valid IPv4 or IPv6 address before comparing it against the allowlist. Use a battle-tested library rather than hand-rolled parsing, because IP addresses can be encoded in many ways (hex, octal, dotted decimal, decimal).
• Compare the validated output, not the raw input — convert the input to its canonical IP form, then check that against the allowlist with strict, case-sensitive comparison. This closes bypasses that encode the address differently.
• Disable redirects in the HTTP client. A validating proxy can follow a redirect to an internal address, bypassing the check that passed on the original URL.

Case 2 — The application must fetch arbitrary external URLs

When a blocklist is the only option, block the destinations that are most dangerous:

These follow the IANA special-purpose registries. Because DNS can resolve a hostname to a blocked address, apply the blocklist to the resolved IP, not just the submitted hostname. Address canonicalization and network segregation add further defense in depth.

Network-layer defenses

When the server must reach arbitrary external hosts, network segregation prevents SSRF from reaching internal systems. Place the outward-facing application in its own network segment, and use firewall rules to block traffic to internal RFC 1918 ranges, link-local metadata addresses, and localhost. This way, even if the application-level validation is bypassed, there is no route from the application to the internal resources it should never reach.

Other hardening measures:

• Restrict non-HTTP schemes — if the application only needs HTTP(S), reject file://, gopher://, ftp:// and other schemes.
• Pin DNS resolution — resolve the hostname once server-side and only allow the connection to that resolved address, mitigating DNS rebinding where a hostname alternates between a public and a private address.
• Static analysis — SAST tooling can flag code paths where a URL built partly from user input reaches an outbound request, helping catch SSRF before it ships.

SSRF vs CSRF

SSRF is often confused with Cross-Site Request Forgery (CSRF), but they are different. CSRF uses a web client — a victim's browser — as the proxy to perform unwanted actions on a site the victim is logged into. SSRF instead uses a vulnerable server as the proxy to make requests the attacker controls, reaching internal systems the attacker could not contact directly. Both are abusing a trusted component to perform unauthorized requests, but on opposite sides of the request path.

FAQ

What is the difference between SSRF and CSRF?

CSRF tricks a user's browser into sending an unwanted request to a site where the user is logged in. SSRF makes a vulnerable server send a request to an internal or external target of the attacker's choosing. CSRF abuses the web client as a proxy; SSRF abuses the server as a proxy and reaches resources the attacker cannot normally contact.

Why is the cloud metadata address 169.254.169.254 important for SSRF?

The link-local address 169.254.169.254 is the instance metadata service for AWS, Google Cloud and Azure. On a server in the cloud, an SSRF that can reach this address may read instance metadata, which can include IAM temporary credentials. This is why cloud providers' metadata addresses are prime SSRF targets and are specifically blocked by SSRF defenses.

What is blind SSRF?

In blind SSRF the response from the target is not returned to the attacker, so they cannot directly read the output. The attacker confirms the vulnerability indirectly — via timing differences, a callback to a server they control, or a side effect triggered on the target — and exploits it based on that evidence.

Can SSRF be used to read local files?

Yes, if the URL-fetching feature supports non-HTTP schemes. A fetcher that accepts file:// can be made to read local files on the server, such as /etc/passwd. SSRF is not limited to HTTP — schemes like ftp://, gopher://, data:// and dict:// can also be abused, and an XXE vulnerability can be chained to perform SSRF.

Summary

SSRF lets an attacker control a request that a vulnerable server makes, turning the server into a proxy to internal systems, the local host, or cloud metadata. The impact ranges from reading a local file to compromising a whole cloud account.

The strongest defense is an allowlist when the application only needs to reach trusted services — validating input and comparing the canonical resolved address. When the application must fetch arbitrary URLs, block dangerous destinations such as metadata services, localhost and private ranges, restrict non-HTTP schemes, and use network segregation so internal systems are unreachable even if application checks are bypassed.

Sources

• OWASP — Server Side Request Forgery (CC BY-SA 4.0)
• OWASP — Server-Side Request Forgery Prevention Cheat Sheet (CC BY-SA 4.0)
• Wikipedia — Server-side request forgery (CC BY-SA 4.0)