SSRF, short for server-side request forgery, is a vulnerability in which an attacker causes a server-side application to send network requests to a destination the attacker chooses, usually an internal service that the attacker cannot reach directly. In application security, SSRF matters because the forged request inherits the network position and trust of the server, turning a harmless-looking feature such as an image fetcher or webhook into a gateway behind the firewall.
The flaw appears wherever an application accepts a URL, hostname or file reference from user input and retrieves it on the server. SSRF has its own category in the OWASP Top 10 (A10:2021), and in cloud environments it has repeatedly been the first step toward stolen credentials and full account compromise.
How SSRF turns a server into a proxy
SSRF works by abusing a legitimate outbound request feature. The application receives a parameter such as url=https://example.com/logo.png, resolves the host, opens a connection and returns or processes the response. If the destination is not restricted, the attacker replaces it with http://127.0.0.1:8080/admin, an internal IP range or a cloud metadata endpoint such as 169.254.169.254.
The server then acts as a confused deputy: it performs the request with its own network access, its own source address and sometimes its own credentials. Internal services often trust any caller from the private network, so an unauthenticated admin panel, a database HTTP interface or a container orchestration API may answer without any login.
Typical entry points share one property: the server, not the browser, makes the request. The following table lists features that commonly carry SSRF risk.
| Feature | Why it fetches a URL | Typical abuse |
|---|---|---|
| Link previews | Reads page titles and images | Fetches internal admin pages |
| Webhooks | Calls a customer-supplied endpoint | Probes internal ports and services |
| Image or PDF import | Downloads a remote file for conversion | Reads metadata endpoints |
| HTML-to-PDF renderers | Loads embedded resources in a headless browser | Loads file:// or internal URLs |
| XML parsers | Resolves external entities | XXE leading to SSRF |
| Single sign-on discovery | Fetches identity provider metadata | Redirects to private hosts |
Variants of server-side request forgery
SSRF variants differ mainly in how much of the response the attacker sees. That visibility determines whether the attacker can read data directly or must infer it from side effects such as timing and error messages.
| Variant | What the attacker observes | Typical impact |
|---|---|---|
| Basic (in-band) SSRF | Full response body returned | Direct data theft, credential exposure |
| Blind SSRF | No response content | Port scanning, triggering internal actions |
| Semi-blind SSRF | Status codes, errors or timing | Service discovery and fingerprinting |
| Out-of-band SSRF | Callbacks to an attacker-controlled server | Confirmation of reachability and exfiltration |
Blind SSRF is often underrated. Even without a readable response, a request to an internal endpoint that changes state, such as a cache purge or a job trigger, can cause real damage. Chained with protocols like gopher://, blind SSRF has historically been used to send raw commands to Redis or Memcached instances that listen on localhost.
SSRF compared with CSRF and other injection flaws
SSRF is frequently confused with CSRF, but the two flaws exploit different parties. CSRF tricks a user’s browser into sending an authenticated request, whereas SSRF tricks the server itself. Comparing SSRF with neighboring vulnerabilities in the same Topic clarifies where each defense belongs.
| Vulnerability | Who sends the request | What is abused | Primary defense |
|---|---|---|---|
| SSRF | The application server | Server network position and trust | Destination allowlisting, network egress control |
| CSRF | The victim’s browser | Session cookies of the user | Anti-CSRF tokens, SameSite cookies |
| Path traversal | The application server | Local file system paths | Canonical path checks |
| XSS | The victim’s browser | Script execution in page context | Output encoding, CSP |
| IDOR | The attacker directly | Missing object-level authorization | Per-object access checks |
SSRF also overlaps with XML external entity (XXE) injection and insecure deserialization, because both can force a parser to fetch remote resources. In practice, an XXE finding is frequently reported as an SSRF when the external entity points to an internal HTTP address.
Why cloud metadata makes SSRF critical
In cloud deployments, SSRF becomes severe because instance metadata services expose temporary credentials over plain HTTP at a link-local address. A vulnerable application on a virtual machine can be asked to fetch the metadata path that returns IAM role credentials, which the attacker then uses from outside to read storage buckets or modify infrastructure.
Cloud providers responded with session-oriented metadata access. AWS IMDSv2 requires a PUT request to obtain a token and a custom header on every subsequent call, and it sets a low IP hop limit so that responses do not leave a container. Google Cloud and Azure require a specific header such as Metadata-Flavor: Google or Metadata: true. These measures block most simple SSRF chains because a typical vulnerable fetcher cannot set custom headers or methods.
Defending against SSRF
Effective SSRF defense combines application-level validation with network-level egress control, because each layer covers gaps in the other. Input validation alone is fragile against parser differences, while network controls alone may still allow abuse of legitimately reachable internal services.
| Control | How it helps | Limitation |
|---|---|---|
| Destination allowlist | Permits only known hosts or domains | Hard to apply to arbitrary user webhooks |
| Resolve-then-check | Validates the resolved IP against private ranges | Must pin the IP to stop DNS rebinding |
| Egress proxy | Centralizes outbound policy and logging | Adds latency and operational overhead |
| Network segmentation | Removes routes to sensitive internal services | Requires mature infrastructure design |
| Disable redirects and schemes | Blocks file://, gopher:// and redirect chains | Needs configuration in every HTTP client |
| Hardened metadata access | Requires tokens or headers for credentials | Protects only the metadata service |
Blocklists of private addresses are a common mistake. Attackers bypass them with decimal or octal IP notation (2130706433 for 127.0.0.1), IPv6 forms such as [::ffff:127.0.0.1], DNS names that resolve to internal addresses, open redirects on allowed domains and DNS rebinding, where the first resolution returns a public address and the second returns a private one. The robust pattern is to resolve once, validate the IP, then connect to that exact IP.
- Run outbound fetchers in a dedicated network zone with no route to internal management interfaces.
- Return generic error messages so blind SSRF cannot map internal ports through error details.
- Log all outbound requests from fetch features and alert on private or link-local destinations.
- Test fetch features with both SAST and DAST tools and include SSRF payloads in input validation tests.
The short version
Imagine a receptionist who will fetch any document you name, from any room in the building. You stand outside, but you can ask for a file from the locked finance office, and the receptionist, who has a key, brings it back. SSRF is that receptionist problem for servers: the attacker cannot enter the internal network, but the server can, and it obeys the request.
The fix is to give the receptionist a short list of rooms they may visit and to lock the doors they should never open. Limit where the server may go, and check every destination before it goes there.
Where it makes a difference
A software company offers a feature that turns any public web page into a PDF report. A security tester enters http://169.254.169.254/latest/meta-data/ as the page address, and the generated PDF contains the list of metadata categories, including the name of the IAM role attached to the virtual machine. A second request returns temporary access keys for that role, which grant read access to a storage bucket with customer exports.
The team fixes the issue in three steps: it switches every instance to token-based metadata access, moves the PDF renderer into an isolated subnet behind an egress proxy that allows only public addresses, and adds a resolve-then-check validator to the URL parameter. A retest confirms that internal, link-local and redirected addresses are all rejected, and the renderer still works for ordinary public pages.