Injection

SSRF (Server-Side Request Forgery): Cloud-Era Attack Vector

How SSRF exploits internal networks and cloud metadata services

What Is SSRF

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a server into making HTTP requests to unintended destinations. The attacker supplies a URL or modifies a request parameter, causing the server to fetch resources from internal networks, cloud metadata endpoints, or other services that should not be directly accessible.

Classified as OWASP A10:2021 – Server-Side Request Forgery and mapped to CWE-918, SSRF gained its own OWASP Top 10 category because of the explosion of cloud-native architectures where internal services are one HTTP request away from the application server.

SSRF is particularly dangerous in cloud environments because cloud providers expose metadata services at well-known internal addresses (e.g., 169.254.169.254) that return instance credentials, API keys, and configuration data.

How SSRF Works

A typical SSRF occurs when an application fetches a URL provided by the user without validating the destination:

// Vulnerable: user controls the URL
app.get('/fetch', async (req, res) => {
  const response = await fetch(req.query.url);
  const data = await response.text();
  res.send(data);
});

An attacker requests: /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

The server makes the request from inside the cloud VPC, where the metadata endpoint is accessible. The response contains temporary AWS credentials (access key, secret key, session token) that the attacker can use to access AWS services.

Cloud Metadata Exploitation

  • AWS: http://169.254.169.254/latest/meta-data/ exposes IAM credentials, instance identity, and user-data scripts
  • GCP: http://metadata.google.internal/computeMetadata/v1/ exposes service account tokens
  • Azure: http://169.254.169.254/metadata/instance exposes subscription and identity information

Real-World SSRF Attacks

  • Capital One (2019): SSRF through a misconfigured WAF allowed an attacker to query AWS metadata, obtaining IAM credentials that exposed 106 million customer records. The breach cost over $300 million.
  • GitLab (2021): An SSRF vulnerability in the project import feature allowed attackers to scan internal networks and access cloud metadata from GitLab instances.
  • Shopify (2020): Researchers discovered SSRF vulnerabilities in webhook and integration features that could access internal services.

The Capital One breach demonstrated how a single SSRF vulnerability in a cloud environment can lead to one of the largest data breaches in history.

How CodeSlick Detects SSRF

CodeSlick detects SSRF patterns across JavaScript, TypeScript, Python, Java, and Go, identifying code that makes HTTP requests with user-controlled URLs without proper validation:

  • Unvalidated URL parameters passed to HTTP client functions (fetch, axios, requests.get, HttpClient)
  • Missing allowlist validation on user-supplied URLs
  • Cloud metadata access patterns targeting known internal endpoints

Findings are mapped to CWE-918 and OWASP A10:2021 with AI-powered fix suggestions that implement URL allowlisting and internal address blocking.

Detect SSRF patterns including cloud metadata access in your codebase.

Frequently Asked Questions

Related Guides

SSRF (Server-Side Request Forgery): Cloud-Era Attack Vector | CodeSlick Security Scanner