Server-Side Request Forgery (SSRF) consistently ranks among the most impactful vulnerabilities we find in web application audits. It's deceptively simple — make the server send a request to an unintended destination — but the impact can be devastating, especially in cloud environments.
What Is SSRF?
SSRF occurs when an application fetches a remote resource based on user-supplied input without properly validating the destination. The server becomes a proxy for the attacker.
Find a URL parameter
Application has a feature that fetches remote content: image preview, URL import, webhook, PDF generation, etc.
Supply an internal URL
Instead of a legitimate URL, send http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint)
Server makes the request
The application server, which is inside the network, fetches the internal resource and returns it
Extract sensitive data
Attacker receives cloud credentials, internal service responses, or infrastructure details
Why SSRF Is So Dangerous in 2026
92%
Cloud-Hosted Apps
$15M
Capital One SSRF Loss
#10
OWASP Top 10
45%
of Audits Have SSRF
The explosive growth of cloud computing made SSRF exponentially more dangerous. Every cloud provider has metadata endpoints accessible from within the network — and SSRF is the key.
The Escalation Chain
Most SSRF findings start small and escalate dramatically:
Stage 1: Basic Internal Access
Internal Network Scanning via SSRF
Port scanning
Send requests to internal IPs (10.0.0.0/8, 172.16.0.0/12) on various ports. Different response times or error messages reveal which hosts and services are alive.
Service discovery
Access internal dashboards, databases, and admin panels that aren't exposed to the internet. Redis, Elasticsearch, Memcached, and internal APIs are common targets.
Metadata services
Cloud metadata endpoints (169.254.169.254 for AWS/GCP, 169.254.169.254 for Azure with specific headers) expose instance configuration, IAM roles, and temporary credentials.
Stage 2: Cloud Credential Theft
This is where SSRF becomes critical:
Access AWS metadata
SSRF to http://169.254.169.254/latest/meta-data/iam/security-credentials/
Retrieve role name
Response reveals the IAM role attached to the EC2 instance
Get temporary credentials
SSRF to http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name] returns AccessKeyId, SecretAccessKey, and Token
Use credentials externally
Attacker uses these credentials from their own machine to access S3 buckets, DynamoDB, Lambda, and any other service the role permits
🛑Capital One Breach
The Capital One breach that exposed 100 million customer records was an SSRF vulnerability. The attacker exploited a misconfigured WAF to perform SSRF, stole IAM credentials from the metadata service, and used them to access S3 buckets containing customer data.
Stage 3: Full Infrastructure Compromise
With cloud credentials, attackers can:
- Read and modify S3 buckets (database backups, user uploads, configuration)
- Access databases through VPC endpoints
- Invoke Lambda functions
- Modify infrastructure through CloudFormation/Terraform state
- Pivot to other services using the stolen role's permissions
Common SSRF Entry Points
Where We Find SSRF
URL import features
Profile picture from URL, document import, RSS feed parsing, website screenshot/preview tools
Webhook configurations
User-configured webhook URLs that the server calls when events occur
PDF/image generation
Server-side rendering that processes HTML with embedded URLs (img src, link href, CSS url())
File processing
SVG parsing (SVG can contain external references), XML parsing (XXE leading to SSRF), document conversion
API integrations
Proxy endpoints, OAuth callbacks, and any feature where the server fetches a user-supplied URL
Bypass Techniques
Attackers don't just try http://169.254.169.254. They use:
- IP encoding tricks —
http://0xa9fea9fe(hex),http://2852039166(decimal),http://0251.0376.0251.0376(octal) - DNS rebinding — A domain that resolves to a public IP on first lookup but an internal IP on second
- URL parser confusion —
http://public.com@169.254.169.254,http://169.254.169.254#@allowed.com - Protocol smuggling —
gopher://,file://,dict://protocols to interact with internal services - Redirect chains — External URL that returns a 302 redirect to an internal address
⚠️Blocklists Don't Work
Blocking 169.254.169.254 and 10.0.0.0/8 seems obvious but is trivially bypassed with IP encoding, DNS rebinding, or redirect chains. Allowlists of permitted domains are far more effective.
Effective Defenses
Weak Defenses
- •Blocklist internal IPs (easily bypassed)
- •Check URL string only (parsers disagree)
- •Rely on WAF rules alone
- •Trust that cloud metadata won't be accessed
Strong Defenses
- •Allowlist of permitted domains/IPs
- •Resolve DNS and validate the IP after resolution
- •Use IMDSv2 (requires token-based metadata access)
- •Network-level isolation for outbound requests
Best practices:
- Enable AWS IMDSv2 (requires a PUT request with hop limit, blocking SSRF from metadata access)
- Use a dedicated outbound proxy for all server-initiated requests
- Validate resolved IPs against an allowlist after DNS resolution
- Disable unnecessary URL schemes (only allow http/https)
- Run URL-fetching services in isolated network segments with no internal access
SSRF is one of the vulnerabilities our AI agents detect most reliably — we test every parameter that could accept a URL. Request a security audit to find SSRF and other server-side vulnerabilities before attackers do.