webSSRFcloud

Server-Side Request Forgery (SSRF): the flaw that opens your cloud

Name: CleanIssue
Price range: €€

Published on 2026-04-037 min readFlorian

What is SSRF

Server-Side Request Forgery forces your server to make HTTP requests to destinations chosen by the attacker. Instead of attacking your internal infrastructure directly, the attacker uses your application as a proxy. This is particularly dangerous in cloud environments where the server has access to internal services not exposed to the internet.

The classic scenario: cloud metadata

All major clouds expose a metadata service accessible only from within instances. On AWS, it's http://169.254.169.254/latest/meta-data/. If your application accepts a user-supplied URL and makes a server-side request (link preview, image import, webhook), the attacker can request this internal address.

Real impact: in 2019, Capital One was breached via an SSRF that allowed retrieval of temporary IAM credentials from the EC2 metadata service. Over 100 million customer records were exposed.

Where SSRFs hide

Link previews: the application fetches the title and image of a URL for display (unfurling)

File import by URL: downloading images or documents from a user-supplied URL

Outbound webhooks: the user configures a callback URL

PDF integrations: generating PDFs from HTML that loads external resources

API proxies: the application relays requests to configurable services

Bypass techniques

Basic filters are easily circumvented:

IP encoding: 169.254.169.254 can be written as 0xa9fea9fe, 2852039166 (decimal), or 0251.0376.0251.0376 (octal)

DNS rebinding: a domain that first resolves to an allowed IP, then to the internal IP on the second resolution

Redirects: the URL points to an attacker-controlled server that redirects (302) to the internal target

Fragments and authentication: http://evil.com@169.254.169.254 can trick some URL parsers

Effective defenses

IMDSv2 on AWS: this mechanism requires a special header to access metadata. It blocks most SSRFs because the attacker can't add headers to the initial request.

Destination allowlist: if your feature only needs a few domains, allow only those. Reject everything else.

DNS resolution then validation: resolve the domain, verify the IP isn't private (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16), then make the request to the validated IP with the original Host header.

Isolated network: run fetch functions in a network that has access to neither metadata nor internal services. Serverless architectures make this isolation easier.

No redirect following: or revalidate each step of the redirect chain.

GCP and Azure too

On GCP, the metadata service is at http://metadata.google.internal/computeMetadata/v1/ and requires the Metadata-Flavor: Google header. On Azure, it's http://169.254.169.254/metadata/instance with the Metadata: true header. Header-based protection makes exploitation harder but not impossible if the application allows controlling the outgoing request's headers.

In our audits

At CleanIssue, we systematically test external fetch features against cloud metadata addresses. SSRF is often combined with other flaws to achieve critical impact. Request your audit call to evaluate your exposure.

Three adjacent analyses to keep exploring the same attack surface.

cloudAWS