Skip to main content
CriticalProtected by PowerWAF

Server-Side Request Forgery (SSRF)

CategoryData Exposure & MisconfigurationOWASPA10:2021 – Server-Side Request ForgeryFirst seen2012Read time7 minVerified2026-02-20
DEFINITION

Server-Side Request Forgery (SSRF) is an attack where the attacker forces a server-side application to make HTTP requests to an arbitrary domain or internal resource. By abusing the server's trusted network position, attackers can access internal services, cloud metadata endpoints, and sensitive data that are not directly accessible from the internet.

How Server-Side Request Forgery (SSRF) Works

SSRF exploits server functionality that fetches external resources (URLs provided by the user). Instead of a legitimate URL, the attacker supplies an internal address, forcing the server to act as a proxy into the internal network.

1

Identify a server-side URL fetch

The attacker finds a feature where the application fetches a remote resource based on user input — such as URL previews, PDF generators, webhook endpoints, or image imports.

2

Supply an internal target

Instead of a public URL, the attacker provides an internal address like http://169.254.169.254/latest/meta-data/ (AWS metadata) or http://localhost:6379/ (Redis) to reach internal services.

3

Bypass URL filters

If basic URL validation exists, the attacker uses bypass techniques: DNS rebinding, IPv6 representations, URL encoding, redirects through controlled domains, or alternative IP formats like 0x7f000001.

4

Exfiltrate internal data

The server's response is returned to the attacker, exposing internal API responses, cloud credentials (IAM role tokens), configuration files, or enabling port scanning of the internal network.

Real-World Examples

2019

Capital One data breach

An SSRF vulnerability in a WAF misconfiguration allowed access to AWS metadata service, exposing 106 million customer records including SSNs and bank account numbers. The breach cost Capital One over $300 million.

2021

GitLab SSRF via webhooks

Multiple SSRF vulnerabilities in GitLab's webhook and import features allowed attackers to access internal network services and cloud metadata from self-hosted instances.

2021

Microsoft Exchange ProxyLogon

A chain of vulnerabilities including SSRF (CVE-2021-26855) in Microsoft Exchange Server was exploited by state-sponsored attackers, compromising over 250,000 servers worldwide.

Impact & Risk Assessment

SSRF is especially dangerous in cloud environments where metadata services expose IAM credentials. Successful SSRF can lead to reading cloud instance credentials, accessing internal databases and APIs, port scanning internal networks, reading local files via file:// protocol, pivoting to Remote Code Execution (RCE) via internal services. In the 2021 OWASP Top 10, SSRF was elevated to its own category (A10) due to increasing prevalence and impact.

How to Detect Server-Side Request Forgery (SSRF)

Monitor outbound requests from application servers for connections to internal IP ranges (10.x, 172.16-31.x, 192.168.x, 169.254.x). Alert on requests to cloud metadata endpoints. Log and analyze all server-side HTTP requests. Inspect DNS resolution logs for internal hostnames. Use network segmentation alerts to detect unexpected cross-zone traffic.

How to Prevent Server-Side Request Forgery (SSRF)

Validate and sanitize all user-supplied URLs on the server side. Implement an allowlist of permitted domains and protocols (deny file://, gopher://, dict://). Block requests to private IP ranges and cloud metadata addresses at the network level. Use a dedicated HTTP client with timeout and redirect limits. Disable unnecessary URL schemes. Deploy IMDSv2 (Instance Metadata Service v2) on AWS which requires session tokens. Segment application servers from sensitive internal services.

Code Examples

Vulnerable: Unvalidated URL Fetch
# VULNERABLE: fetches any URL the user provides
@app.route('/preview')
def preview():
url = request.args.get('url')
response = requests.get(url) # No validation!
return response.text

# Attacker request:
# /preview?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
Secure: URL Validation with Allowlist
import ipaddress
from urllib.parse import urlparse

ALLOWED_HOSTS = {'api.example.com', 'cdn.example.com'}
BLOCKED_RANGES = [
ipaddress.ip_network('10.0.0.0/8'),
ipaddress.ip_network('172.16.0.0/12'),
ipaddress.ip_network('192.168.0.0/16'),
ipaddress.ip_network('169.254.0.0/16'),
]

def is_safe_url(url):
parsed = urlparse(url)
if parsed.scheme not in ('http', 'https'):
return False
if parsed.hostname not in ALLOWED_HOSTS:
return False
try:
ip = ipaddress.ip_address(parsed.hostname)
return not any(ip in net for net in BLOCKED_RANGES)
except ValueError:
return True # hostname, not IP — check against allowlist

PowerWAF automatically blocks Server-Side Request Forgery (SSRF) at the edge.

Deploy in minutes. No code changes required. Free plan available.

Free plan spots are limited

Frequently Asked Questions

Cloud providers like AWS, GCP, and Azure expose metadata services at well-known internal IPs (169.254.169.254). These services return temporary credentials, API keys, and configuration data. SSRF allows attackers to reach these endpoints from the server, effectively inheriting the server's cloud permissions.
In blind SSRF, the server makes the request but doesn't return the response to the attacker. The attacker can still confirm the target is reachable by measuring response times, observing DNS lookups, or using out-of-band techniques (like making the server contact an attacker-controlled server).
A WAF can detect and block many SSRF attempts by inspecting request parameters for internal IP addresses, cloud metadata URLs, and common bypass patterns. PowerWAF includes specific SSRF rule sets that detect encoded IPs, DNS rebinding attempts, and redirect chains targeting internal resources.