SSRF Explained: Server-Side Request Forgery & Cloud Metadata

Give an application a feature that fetches a URL, and you may have handed an attacker a way to reach every system that application can reach. That is server-side request forgery, SSRF, and in cloud environments it has become one of the highest-impact web vulnerabilities there is.

The mechanics are almost embarrassingly simple, which is part of why the bug is so common. The damage, on the other hand, can be total.

The core idea

Many applications make outbound requests on the user's behalf. A webhook that calls back to a URL you provide. A "preview this link" feature. A PDF generator that renders a page you specify. An avatar uploader that accepts an image URL. In each case, the server makes the request, using the server's network position and the server's trust.

SSRF is what happens when the attacker controls where that request goes. Instead of pointing the feature at a normal external URL, they point it inward:

https://your-app.example/fetch?url=http://internal-admin-panel.local/

The internal admin panel is not reachable from the public internet. Firewalls see to that. The application server, sitting inside the network, reaches it easily. By forging the request through the trusted server, the attacker borrows its access. A backend that was meant to fetch public images becomes a proxy into the internal network.

Why the cloud made SSRF critical

SSRF existed for years as a moderate-severity nuisance. Cloud computing turned it into a crown-jewels bug, because of one design choice shared across the major providers: the instance metadata service.

Cloud virtual machines can query a special internal address to learn about themselves, including, on default configurations, temporary credentials for the role the instance is running as. That address is reachable only from the instance itself. Which is to say, reachable from any process on the instance, including a web app with an SSRF flaw.

Chained together, the attack is short and brutal: SSRF the application into requesting the metadata endpoint, read back the temporary cloud credentials, then use them to act as the instance across the cloud account. On MITRE ATT&CK this is Cloud Instance Metadata API abuse (T1552.005), and it has featured in some of the largest cloud breaches on record.

Basic vs blind SSRF

Basic (in-band) SSRF returns the response of the forged request to the attacker. They see the internal admin page, the metadata output, the internal API response. This is the easiest to exploit and the easiest to notice.

Blind SSRF does not return the response. The application makes the request but discards the body, or only tells you whether it succeeded. It is still exploitable:

• Out-of-band detection. Point the request at a server the attacker controls and watch for the callback. If it arrives, the SSRF is real, and the source IP and DNS lookups reveal internal details.
• Timing. A request to an open internal port responds differently from a closed one. Response-time differences let an attacker map the internal network blind.
• Side effects. Even without reading a response, forcing the server to hit an internal endpoint can trigger actions: restarting a service, sending an internal request that changes state.

Blind SSRF is quieter and slower, but it is not safe.

Where SSRF hides

The vulnerability lives anywhere a server turns user input into an outbound request. The usual suspects:

• Webhook and callback URL fields
• Link-preview and unfurling features
• Server-side PDF and screenshot generators
• Image and file proxies, "import from URL" uploaders
• Document converters and XML/PDF parsers that follow external references
• Integrations that let a user configure an endpoint

Any of these is worth a hard look during review.

Why input filtering fails

The instinct is to block bad-looking URLs: reject anything pointing at localhost, 127.0.0.1, or private IP ranges. Attackers have a deep bag of tricks to defeat exactly this:

• Alternate encodings of the same address (decimal, octal, hex, IPv6-mapped forms).
• DNS rebinding, where a hostname resolves to a safe address when validated and a dangerous one when fetched.
• Redirects, where an allowed URL responds with a redirect to an internal target and the server follows it.
• Obscure schemes, where file://, gopher:// or others reach places http filters did not consider.

Blocklists lose this race. The list of things to block is open-ended, and the attacker only needs one bypass.

How to actually defend against SSRF

The controls that hold up share a principle: decide where the server is allowed to go, and deny everything else.

1. Allowlist outbound destinations. For each URL-fetching feature, define the small set of domains or hosts it legitimately needs and reject the rest. Deny by default. This is the single most effective control.
2. Validate after resolution, and pin it. Resolve the hostname, confirm the resulting IP is in your allowed set, and connect to that exact IP so DNS cannot change under you (defeating rebinding).
3. Do not follow redirects blindly. If you must, re-validate every hop against the allowlist.
4. Restrict schemes and ports to what the feature needs, normally just https on 443.
5. Enforce IMDSv2 (or your provider's hardened metadata mode) so the metadata service requires a token an SSRF cannot easily supply.
6. Segment the network. Put URL-fetching services where they cannot reach internal admin planes or sensitive services. When the app-layer control fails, segmentation caps the damage.

SSRF is a small bug with an outsized reach. It costs an attacker one controllable URL and gives them the network position of your trusted backend. Build the URL-fetching features in your app on a deny-by-default allowlist from the start, harden the cloud metadata service, and segment the network behind them, and you remove both the easy win and the catastrophic one.

A worked SSRF walkthrough

It helps to trace a single attack from the outside in, because the individual steps are each unremarkable and the danger lives in how they chain.

Picture an application with a profile page that lets you set an avatar by pasting an image URL. The server fetches that URL, resizes the image, and stores the result. A normal request looks like https://cdn.example.com/cats/tabby.png, and the server dutifully downloads it. Nothing about the feature looks risky. It is a convenience most products ship without a second thought.

The attacker starts by confirming the server, rather than the browser, makes the fetch. They host a URL on infrastructure they control and paste it in. When their own server logs an inbound request from the application's egress IP address rather than from the attacker's home connection, the behaviour is confirmed. The application is a request engine that will call arbitrary destinations.

Next they probe inward. They swap the external URL for http://127.0.0.1:8080/ and watch how the application responds. An error that mentions a connection refused on one port and a different response on another is a map of what services listen on the loopback interface. The attacker walks common ports, learning that an internal admin service answers on one of them, all without the target service ever being exposed to the internet.

Then they reach for the prize. On a cloud instance they point the avatar fetcher at the link-local metadata address and request the path that lists instance roles, then the path that returns temporary credentials for a role. If the metadata service is running in its unauthenticated mode, the response is a small block of text containing an access key, a secret, and a session token. The attacker copies those into their own tooling and now holds valid, if temporary, credentials for the cloud account.

From there the damage is a function of what that role can do. A role scoped to a single storage bucket leaks that bucket. A role with broad permissions, which is depressingly common, opens the whole account. The entry point was a box that asked for an image URL. Every step after it was legitimate machinery doing exactly what it was built to do, pointed somewhere it was never meant to go.

Detection signals

SSRF is quiet by nature, because the malicious request comes from your own trusted server and often looks like ordinary outbound traffic. The signals that give it away tend to sit in logs people do not routinely watch.

• Outbound requests to internal or link-local addresses. A URL-fetching service that suddenly connects to 169.254.169.254, 127.0.0.1, or an RFC 1918 private range is the clearest tell there is. Egress logs and proxy logs are where this shows up.
• Metadata endpoint access in application context. Any hit on the instance metadata service that originates from a web-facing process, rather than from expected system tooling, deserves an alarm. On hardened setups this path should almost never be walked by the application itself.
• A spike in fetch errors across many hosts or ports. Blind SSRF probing produces a scatter of connection attempts to addresses and ports the feature has no business touching. A burst of timeouts and refusals clustered in time is a fingerprint of internal port scanning through the app.
• Requests whose destination hostname resolves to a private IP. Logging the resolved address alongside the requested hostname catches DNS rebinding and cases where an allowed domain quietly points inward.
• Redirect chains that end on internal targets. If your fetcher follows redirects, a request that starts at a public URL and lands on an internal one is worth capturing and reviewing.
• Out-of-band callbacks you did not initiate. Interaction with unexpected external domains, especially freshly registered ones, can indicate an attacker using a callback listener to confirm blind SSRF.

SSRF compared to related web bugs

SSRF gets confused with a handful of neighbouring vulnerabilities because several of them involve URLs, redirects, or requests crossing a trust boundary. The distinctions matter, because the fixes differ.

The pattern to hold on to: CSRF and open redirect abuse the trust a browser has, while SSRF and XXE abuse the trust and network position a server has. SSRF and XXE often blur together because a permissive XML parser is one of the classic ways to trigger SSRF, and DNS rebinding is less a separate bug than a technique that makes SSRF filtering fail.

Common misconceptions

"We validate the URL, so we are safe." Input validation on the string the user submits is the control attackers spend the most effort defeating. Alternate IP encodings, redirects, and DNS rebinding all pass a naive string check and still reach an internal target. Validation has to happen after DNS resolution, against the actual IP the connection will use, with that IP pinned for the connection.

"Blind SSRF is low severity because nothing comes back." Not seeing the response only removes the easiest exploitation path. Timing differences map internal services, out-of-band callbacks confirm reachability, and forced internal requests trigger state changes. Blind SSRF has led to full credential theft in cases where the metadata response was exfiltrated through a side channel.

"Only public-facing apps are at risk." An internal service with an SSRF flaw is often a more valuable pivot, because it already sits deep in the network. Any service that fetches URLs on someone else's behalf is a candidate, wherever it lives.

"Blocking localhost and private ranges is enough." Blocklisting is a losing race against an open-ended set of bypasses. The metadata address itself is a link-local address that people frequently forget to include, and even a complete blocklist falls to rebinding. Allowlisting the small set of destinations a feature legitimately needs is the control that holds.

"IMDSv2 fixes SSRF." Hardening the metadata service removes one specific and catastrophic target. It does nothing about SSRF reaching internal admin panels, databases, or other services. It is a critical layer, and it is not the whole defence.

How SSRF became a cloud problem

SSRF is not new. Server-side request forgery was described and exploited for years as a moderate-severity issue, useful mainly for reaching internal services on a flat network or scanning ports from inside a perimeter. It rarely topped a severity list, because the payoff was usually reconnaissance rather than direct compromise.

Two shifts changed its standing. The first was the move to cloud infrastructure and the arrival of the instance metadata service as a standard feature. Suddenly every cloud virtual machine carried a local endpoint that would hand out credentials to whatever process asked, and SSRF was the way for a web application to become that process. A reconnaissance bug turned into a credential-theft bug overnight, and several of the largest publicly discussed cloud breaches followed that exact path.

The second shift was architectural. Modern applications are meshes of services that call one another over HTTP, pull in webhooks, generate link previews, render pages to PDF, and import data from URLs. Every one of those features is a place where user input can steer a server-side request. As the number of URL-fetching features per application grew, so did the attack surface.

The industry response was to promote SSRF into the OWASP Top 10 as its own category, a recognition that it had graduated from a niche finding to a systemic risk. Cloud providers responded by hardening the metadata service, offering a token-based mode that a naive forged request cannot satisfy. The technique and its defences have been co-evolving since, which is why the durable answer is architectural rather than a single patch.

Beyond the metadata endpoint

The metadata service gets the headlines, and it is worth knowing the other destinations that make SSRF valuable, because hardening one target does not retire the technique.

Internal APIs are a frequent second prize. Many organisations run administrative and orchestration APIs that trust any request arriving from inside the network and skip authentication on the assumption that the perimeter keeps outsiders away. SSRF puts the attacker inside that perimeter, so those APIs answer as if the request were legitimate. Container and orchestration platforms often expose control endpoints on the loopback interface or a private address, and reaching them can mean scheduling workloads, reading secrets, or listing the whole cluster.

Databases and caches that bind to an internal interface are reachable too, especially through protocol-smuggling tricks. Some SSRF flaws allow schemes beyond http, and a scheme like gopher can be abused to send crafted bytes to a service that speaks a line-based protocol, effectively letting the forged request issue commands to an internal cache or queue. This is why restricting the allowed schemes to exactly what a feature needs, usually https alone, matters as much as restricting the destination.

Cloud provider APIs and internal identity endpoints round out the list. Once an attacker holds credentials pulled from the metadata service, the same SSRF or the stolen keys can be turned against the provider's own management interfaces. The lesson is consistent: the value of SSRF scales with everything the trusted server can reach, so the defence has to constrain that reach rather than guard a single famous address.

Frequently asked questions

Is SSRF only an issue in the cloud? No. SSRF is exploitable anywhere a server makes requests on behalf of a user, including on-premise networks where it can reach internal admin interfaces, databases, and other services. The cloud metadata angle is what raised its ceiling to full account compromise, which is why cloud environments get the most attention.

What is the difference between SSRF and CSRF? They sound alike and are unrelated in mechanism. CSRF tricks a victim's browser into sending an authenticated request the user did not intend. SSRF tricks a server into sending a request to a destination the attacker chose. CSRF abuses browser trust, SSRF abuses server trust and network position.

Can HTTPS or a web application firewall stop SSRF? Not reliably. Encryption protects data in transit and does nothing about where a request is aimed. A firewall tuned for inbound attacks may not inspect the outbound requests SSRF generates, and payloads that use alternate encodings or redirects routinely slip past signature-based rules. The effective controls live in the application and network design.

What is IMDSv2 and why does it matter? It is the hardened mode of the cloud instance metadata service that requires a session token obtained through a specific request before it will return credentials. A basic SSRF that simply fetches the metadata URL cannot supply that token, which closes the single most damaging SSRF path. It should be enforced on every instance.

How do I test my own application for SSRF? Identify every feature that fetches a URL, then point each one at a server you control and confirm whether the request arrives from your application's egress address. From there, test internal addresses, the metadata endpoint, alternate IP encodings, and redirect following. Do this only against systems you own or are authorised to test.

Does allowlisting outbound destinations break legitimate features? It requires you to know what each feature legitimately needs to reach, which is a healthy thing to know anyway. Most URL-fetching features talk to a small, stable set of domains. The rare feature that must fetch genuinely arbitrary user URLs should be isolated on infrastructure that cannot reach anything sensitive, so a forged request lands nowhere useful.

Is SSRF still relevant now that metadata services are hardened? Yes. Hardening removed the easiest catastrophic target, and SSRF still reaches internal services, databases, admin panels, and other cloud endpoints. It remains an OWASP Top 10 category because the underlying pattern, a server making attacker-controlled requests, is baked into how modern applications are built.

Related guides

• OWASP Top 10 Explained
• CSRF Explained
• Cloud Misconfigurations Guide
• API Security Guide
• Cloud Security Fundamentals