SSRF and cloud metadata: a dangerous combination

Server-side request forgery used to be a medium-severity curiosity: make the server fetch a URL it shouldn't. Then everything moved to the cloud, where a well-placed SSRF can reach the instance metadata service, pull temporary credentials, and turn one web bug into control of the cloud account.

What SSRF is

SSRF happens when an application fetches a URL supplied — directly or indirectly — by the user, without restricting where it can go. Image importers, webhook testers, PDF generators, URL previews, "fetch from link" features: anywhere the server makes an outbound request on your behalf is a candidate. The attacker's goal is to point that request somewhere internal.

Why the cloud makes it critical

Cloud instances expose a metadata endpoint on a link-local address that returns configuration — and, crucially, temporary credentials for the role attached to the instance. An SSRF that can reach it reads those credentials and then acts as the instance against the cloud provider's APIs. Depending on the role's permissions, that can mean reading storage buckets, databases, or escalating across the account. One unvalidated fetch becomes a breach.

How to defend

• Enforce the hardened metadata service. Require the session-oriented metadata version (IMDSv2-style) so a simple GET can't lift credentials; disable the legacy endpoint.
• Least-privilege instance roles. If credentials are stolen, their blast radius is only as big as the role. Scope roles tightly.
• Allow-list egress. The application should only be able to reach the destinations it legitimately needs. Block link-local and internal ranges by default.
• Validate and re-validate URLs. Resolve and check the destination after redirects; don't trust a one-time check that a redirect can bypass.

SSRF is a reminder that severity is contextual. The same bug that's a shrug on a static host is a crisis next to a credential-bearing metadata service. We rate it for where it actually sits — and in the cloud, that's usually near the top.

Blind SSRF still hurts

Not every SSRF hands the response back to the attacker. “Blind” SSRF — where you can make the server send a request but can’t see the result — is often downgraded or dismissed, which is a mistake. It still reaches internal services, still drives actions, and out-of-band techniques (DNS and HTTP callbacks) confirm it fired. The cloud metadata service in particular doesn’t care whether you can read the response in your browser; a request that reaches it can still trigger effects. Treat blind SSRF as real and rate it for where it can reach, not for how convenient it is to demonstrate.

Beyond the cloud: internal pivots

Even with no metadata service in reach, SSRF is dangerous. It reaches internal admin panels, databases and dashboards that trust anything “from inside,” and it can map the internal network one request at a time. The lesson is defence in depth: patching the metadata endpoint matters, but so do egress controls and requiring real authentication on internal services, so that “the request came from our own server” stops being a free pass.

Why IMDSv2 session binding specifically defeats basic SSRF

The first version of the AWS instance metadata service answered any process that could reach the link-local address with a plain GET request. That is precisely the shape of request a vulnerable server will happily make on an attacker's behalf, which is why SSRF and metadata became such a potent pairing. IMDSv2 changes the conversation model rather than the address: before any credential can be read, the caller must first perform a PUT to obtain a short-lived session token, then present that token as a header on every subsequent request.

This is effective against most SSRF not because the token is secret, but because of the verbs and headers involved. The overwhelming majority of SSRF primitives are limited to issuing an outbound GET at a URL the attacker influences. They cannot choose the HTTP method, cannot set an arbitrary request header, and cannot carry the response of one request forward as input to the next. A session that requires a PUT, a custom token header, and two correlated round trips simply does not fit through a single attacker-controlled GET. IMDSv2 also lets the platform cap the response hop limit, so a token request that has been bounced through a container network layer is discarded rather than answered.

DNS rebinding and time-of-check/time-of-use validation

A great deal of SSRF defence is built on a single validation step: resolve the hostname, confirm the address is not internal or link-local, and allow the request. The weakness is temporal. Between the moment the application checks an address and the moment the HTTP client actually connects, a name can be re-resolved to a different address. An attacker who controls a domain's authoritative responses can return a harmless public address for the validation lookup and a sensitive internal address for the connection that follows. This is classic time-of-check/time-of-use (TOCTOU), and it defeats validators that trust a name instead of a connection.

The conceptual fix is to collapse the gap: resolve once, decide on the resolved address, and then connect to that same address rather than resolving the name a second time inside the HTTP library. Equally important is to validate the destination of every hop, not just the first.

Redirects, parser confusion, and why a one-time allow-list fails

A URL is parsed by more than one component, and they do not always agree. The validator, the HTTP client, and any downstream proxy may each interpret authority, embedded credentials, encoded characters or unusual host forms differently. When the component that decides and the component that connects disagree, an address that passed the check is not the address that is dialled. Redirects compound this: a permitted URL may return a 3xx response pointing somewhere internal, and a client that follows redirects blindly will chase it past the gate. A one-time allow-list check at submission is therefore necessary but never sufficient.

Cloud-provider nuances and out-of-band monitoring

Metadata services differ in ways that matter to defenders. AWS has moved the industry towards the session-bound model described above. Azure's instance metadata endpoint requires a specific request header to be present before it will respond, which blocks naive header-less SSRF. Google Cloud similarly gates its metadata responses behind a required header. The common thread is that modern providers demand something an ordinary GET cannot supply, so the safest posture is to assume no provider's defaults are uniform and to harden each environment to its own strictest setting.