Server-Side Request Forgery (SSRF) has evolved from an interesting but niche web application vulnerability into one of the most critical attack vectors in cloud environments. The fundamental mechanism — an attacker causes a server-side application to make HTTP requests to an attacker-specified destination — has existed for years. What changed is the environment in which it operates. Cloud infrastructure metadata services, internal service meshes, and the prevalence of server-side URL fetching in modern web applications have transformed SSRF from a vulnerability that might leak internal IP addresses into an attack chain that can yield cloud credentials, internal service access, and complete environment compromise.
The Capital One breach in 2019 is the canonical illustration of cloud SSRF exploitation. A misconfigured AWS WAF allowed an attacker to exploit an SSRF vulnerability in a Capital One web application. The SSRF was used to query the EC2 Instance Metadata Service (IMDS) at 169.254.169.254, which returned IAM role credentials attached to the EC2 instance. Those credentials were then used to access S3 buckets containing over 100 million customer records. The entire attack chain — SSRF to metadata service to IAM credentials to S3 — is a textbook cloud SSRF exploitation sequence that has been replicated in dozens of subsequent incidents.
The Cloud Metadata Services
AWS EC2 Instance Metadata Service
The AWS IMDS is available at http://169.254.169.254/latest/meta-data/ from any EC2 instance. It provides instance configuration data, network settings, and, critically, IAM role credentials at http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]. The returned credentials include an AccessKeyId, SecretAccessKey, and Token that can be used with the AWS CLI or SDK to make API calls with the permissions of the attached IAM role. IMDSv2, introduced by AWS in 2019, requires a session-oriented approach: callers must first make a PUT request to obtain a session token before the metadata endpoint will serve data. This breaks the simple GET-based SSRF exploitation chain because most SSRF vulnerabilities only allow GET requests. IMDSv2 should be enforced (not merely available) on all EC2 instances, and can be enforced at the account level via AWS Organizations SCP.
GCP Metadata Server
Google Cloud's metadata server is accessible at http://metadata.google.internal/computeMetadata/v1/ and requires a Metadata-Flavor: Google header. Service account tokens are available at http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token. The header requirement partially mitigates SSRF exploitation — an SSRF that can only control the URL but not add headers cannot directly access the metadata server. However, SSRF vulnerabilities that allow header injection, or server-side HTTP clients that forward request headers, can bypass this protection. GCP recommends using Workload Identity Federation instead of service account keys to reduce the blast radius of metadata credential theft.
Azure Instance Metadata Service
Azure IMDS is available at http://169.254.169.254/metadata/instance with a required Metadata: true header. Managed identity tokens for Azure resources are available via the IMDS and can be used to authenticate to Azure services. Like GCP, the header requirement provides some SSRF mitigation, but is not a complete defense against header-forwarding SSRF vulnerabilities.
SSRF Variants and Bypass Techniques
Basic vs. Blind SSRF
Basic SSRF returns the server's response to the attacker — the web application fetches the URL and displays or forwards the response content. This is the most directly exploitable form. Blind SSRF does not return response content, but the server still makes the request — the attacker can infer success based on response time, error messages, or out-of-band DNS/HTTP callbacks. Blind SSRF is detected using interactivity services like Burp Collaborator or interactsh, which provide unique URLs that log any DNS or HTTP interaction. A web application that makes DNS lookups to attacker-supplied hostnames without returning response content is still vulnerable to blind SSRF — it can be used to map internal network topology, detect internal services, and in some configurations exploit internal APIs that do not require authentication.
Protocol Smuggling
SSRF is not limited to HTTP. Server-side HTTP clients that support alternative URL schemes can be exploited to access local files (file:///etc/passwd), interact with Redis via gopher://127.0.0.1:6379/_RESP protocol commands, send SMTP commands via gopher://127.0.0.1:25/, or interact with other internal services using their native protocols. The Gopher protocol is particularly powerful for SSRF exploitation because it allows raw bytes to be sent to any TCP port, effectively enabling protocol tunneling over SSRF. Testing should include attempts with file://, gopher://, dict://, and ftp:// schemes in addition to http://.
Filter Bypass Techniques
Applications that attempt to block SSRF via URL filtering frequently implement insufficient denylists. Common bypass techniques include: IPv6 representations of blocked IPv4 addresses (http://[::ffff:169.254.169.254]/), decimal and octal IP representations (http://2852039166/ for 169.254.169.254), URL encoding of IP components, DNS rebinding (registering a domain that resolves to a public IP on first lookup but to 169.254.169.254 on subsequent lookups, defeating time-of-check-to-time-of-use TOCTOU validation), HTTP redirects from an attacker-controlled server to the target internal address (if the server-side client follows redirects, the first request hits the attacker's public server, which returns a 301 redirect to the internal target), and IDNA homograph domains that resolve to internal addresses. CVE-2019-8942, a WordPress Path Traversal and Local File Inclusion vulnerability, was chained with its companion CVE to achieve Remote Code Execution on WordPress instances (NVD) — demonstrating that flaws in feature-rich applications can chain to higher-severity outcomes.
Application-Level Remediation
Allowlist-based URL validation is the most effective application-level SSRF defense: if the application only needs to fetch content from specific known domains, validate the fully resolved destination against an explicit allowlist rather than attempting to block known-bad addresses. Resolve the hostname to an IP address and validate the IP against a blocklist of private and link-local ranges (RFC 1918, RFC 3927, and cloud metadata ranges) — but do so after resolution to prevent DNS rebinding bypass. Disable URL scheme support for anything other than https://. If possible, route outbound server-side HTTP requests through a dedicated egress proxy with its own access controls, so that metadata service access is blocked at the network layer regardless of application-level filter effectiveness. Fortress MSSP's web application penetration testing service includes comprehensive SSRF testing covering all metadata service endpoints, filter bypass techniques, and protocol smuggling. Contact us to schedule an assessment.