Server-Side Request Forgery (SSRF) tricks a server into making HTTP requests on an attacker’s behalf, targeting internal systems the attacker can’t reach directly. In cloud environments, that almost always means one thing: the metadata service, which hands out credentials that can compromise your entire cloud account.
Pithy Security | Cybersecurity FAQs – The Details
Question: What is SSRF and why is it so dangerous in cloud environments?
Asked by: DeepSeek V3
Answered by: Mike D (MrComputerScience) from Pithy Security.
How SSRF Turns Your Own Server Into an Attacker’s Proxy
SSRF exploits any feature where a server fetches a URL based on user-supplied input. Think webhook configurations, PDF generators that render remote content, URL preview functionality, or image import tools.
The attacker doesn’t send a link to an external site. They send an internal address. The server fetches it, and the response comes back through the application. From the attacker’s perspective, they’ve just borrowed the server’s network identity.
On a plain corporate network, that’s bad. The attacker can reach internal services, admin panels, and databases that aren’t exposed to the internet. But the blast radius is usually contained.
In a cloud environment, it’s a different threat entirely. Every major cloud provider runs an instance metadata service at a well-known, non-routable IP address. On AWS, that’s 169.254.169.254. On GCP and Azure, similar endpoints exist. Those services return temporary IAM credentials, environment variables, and configuration data for whatever instance is running your application.
One successful SSRF request to that address and the attacker has credentials that can enumerate your cloud environment, pivot to other services, and exfiltrate data at scale. The Capital One breach in 2019 followed exactly this pattern.
Why Cloud Metadata Services Make SSRF Critically Exploitable
The metadata endpoint was designed for convenience, not adversarial conditions. It requires no authentication by default. Any process running on the instance can query it, including a vulnerable web application acting on behalf of an attacker.
AWS introduced IMDSv2 to address this. It requires a session-oriented token obtained via a PUT request before metadata is returned, which breaks the simple GET-based SSRF exploit. But IMDSv2 isn’t enforced by default on older instances. Many organizations still run IMDSv1 because migration requires testing and coordination, and the credential theft scenario feels abstract until it isn’t.
The problem compounds in microservices architectures. In a containerized environment, a single SSRF-vulnerable service can reach internal APIs, secrets managers, and other containers that were never meant to face external traffic. The network perimeter you thought existed doesn’t. The vulnerable service is inside it.
OWASP ranked SSRF as its own category (A10) in the 2021 Top 10, partially because cloud adoption made the severity profile much worse than it was in the on-premises era.
When SSRF Mitigations Actually Block Cloud Credential Theft
The most reliable mitigation is enforcing IMDSv2 on every EC2 instance and equivalent protections on GCP and Azure. It’s a configuration change, not a code change, and it specifically breaks the SSRF-to-metadata-credential-theft chain.
Beyond that, egress filtering matters. If your application has no business reason to reach internal IP ranges like 169.254.0.0/16, 10.0.0.0/8, or 172.16.0.0/12, block those ranges at the network layer. Don’t rely solely on application-level input validation.
Allowlisting outbound requests by domain or IP is stronger than blocklisting. Blocklists are bypassable with redirects, URL encoding tricks, and alternate IP representations like decimal or hex format. If your PDF generator only needs to fetch assets from one CDN, restrict it to that CDN.
WAF rules from AWS, Cloudflare, and others include SSRF-specific signatures, but they’re pattern-matching on known payloads. They catch low-effort attempts. A motivated attacker will find encodings and redirect chains that bypass them.
Detection matters too. Unusual outbound requests from application servers, especially to metadata IP ranges, should fire alerts. GuardDuty on AWS flags IMDSv1 credential exfiltration patterns. Use it.
What This Means For You
- Enforce IMDSv2 on all EC2 instances now by setting
HttpTokens: requiredin your instance metadata options, which blocks credential theft via simple SSRF GET requests. - Audit every application feature that fetches user-supplied URLs and apply strict allowlist validation on destination hosts rather than trying to blocklist known-bad inputs.
- Block egress to cloud metadata IP ranges (169.254.169.254 and equivalents) at the network layer for any service with no legitimate reason to reach them.
- Enable AWS GuardDuty or equivalent cloud-native threat detection to alert on anomalous metadata service queries and credential usage from unexpected sources.
Related Questions
Want Cybersecurity Breakdowns Like This Every Week?
Subscribe to Pithy Security (Free) → pithysecurity.substack.com