SSRF Explained — How Server-Side Request Forgery Works, Attack Techniques, and Defenses

Web applications often have a feature like "take a URL and fetch its contents on the server side". Preview generation, external API integration, webhooks, file ingestion, PDF rendering, image resizing, OG image fetching — common everywhere.

When the URL is passed straight to an HTTP client without validation, the attacker can force the server to hit any destination. Not just outside addresses like https://evil.example/, but also addresses that only the server itself should be able to reach from the inside — http://127.0.0.1:8080/admin, http://169.254.169.254/, and so on.

Don't confuse it with CSRF — the structure is reversed #

CSRF (Cross-Site Request Forgery) makes the victim's browser send a request to the target site. The attacker borrows the victim's cookies and authentication. SSRF, by contrast, makes the target site's server send a request to some other server. The attacker borrows the server's IP / IAM role / internal reachability. The victim's session has nothing to do with it. Both "forge a request", but the attack surface and defenses are completely different.

Placement in the OWASP Top 10 #

The 2021 edition added it as a standalone category, A10:2021 — Server-Side Request Forgery. Until then, it was scattered across "Injection" and "Broken Access Control", but as IAM theft via SSRF became common in the cloud era, the OWASP community vote placed it first, and it was separated out. It is now treated as a representative modern Web vulnerability.

SSRF has been a classic vulnerability for 20+ years, but only in the late 2010s — after cloud went mainstream — did it become widely seen as "critical". The reason is clear.

Cloud metadata endpoints #

AWS / GCP / Azure and other IaaS providers let each instance fetch short-lived credentials tied to its IAM role from a special local IP.

These endpoints respond without authentication to HTTP requests from the instance itself. By design that's "instance-local traffic" and considered safe — but SSRF breaks that assumption: external attackers force the server to hit its own metadata, and the response (including IAM credentials) is returned to them.

Internal networks and service meshes #

Even outside the cloud — within corporate networks, inside Kubernetes clusters, inside service meshes — the design assumption is often "if you're inside the same network, mutual auth is unnecessary or loose". SSRF is the ticket that makes the attacker a "person on the inside".

• Hit http://kube-apiserver/api/v1/... from inside a Kubernetes Pod
• Internal admin dashboards (Jenkins / Grafana / Kibana / Consul) listening without auth
• Internal URLs for LDAP / Active Directory / Confluence / GitLab
• localhost:6379 Redis, localhost:9200 Elasticsearch (both unauthenticated by default)

So SSRF is "an attack entry point", not just a single vulnerability #

Unlike XSS or SQLi where "this vulnerability alone causes the damage", SSRF is the starting point of lateral movement. Getting one SSRF opens up 10 to 100 additional attack surfaces beyond it. That's why it's "devastating in the cloud era".

Classified by how the response is visible to the attacker. Detection difficulty and ease of exploitation differ dramatically.

Basic SSRF (full response visible) #

The server returns the fetched response as-is back to the requester. The most exploitable type.

Typical scenarios: "Paste a URL, get a preview" APIs, PDF generators, URL-based image converters. The attacker submits ?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the response JSON contains the full metadata.

Blind SSRF (response invisible, but side effects possible) #

The server fires the request but does not return the response body to the attacker. Common in "ping this webhook" / "store something based on this URL" flows. Direct information exfiltration is harder, but you can still:

• Timing differential — infer reachability of internal hosts from response time (192.168.0.1 returns in milliseconds, unused IPs time out after seconds)
• Internal APIs with side effects — even without reading the response, the attacker can trigger state-changing operations on internal APIs (delete, transfer, grant)
• OOB (Out-of-Band) detection — observe via a separate channel whether the server made a request to an attacker-controlled DNS / HTTP server. Burp Collaborator is the standard tool

Semi-Blind SSRF (partially visible) #

The full body is not returned, but fragments — HTTP status code / Content-Length / error messages — are observable. Enough for port scanning. "200 OK = open, 500 = closed or invalid response" gives you a map of internal services.

Minimal vulnerable code #

file_get_contents / curl / requests.get / fetch — in any language, passing user-supplied URLs through the HTTP client unchanged results in SSRF.

The scheme-restriction trap #

It's tempting to think "just allow http:// and https://", but some HTTP clients support many other schemes.

PHP's curl_init allows many schemes by default. You must explicitly constrain via CURLOPT_PROTOCOLS.

URL parser / normalization pitfalls #

Defenders think "just block 127.0.0.1 and localhost", but attackers can express the same host in countless representations.

Blacklists are always bypassed. The defenses below boil down to "resolve DNS first, then check the final IP against private/loopback/link-local ranges".

DNS Rebinding #

A particularly nasty technique. The attacker controls a DNS server that returns a public IP on the first lookup and 127.0.0.1 on the second. If the server's flow is "① validate URL → DNS lookup, then ② send HTTP request → DNS lookup again" (two separate lookups), the IP gets "rebound" between validation and the actual request, defeating the check.

The fix is simple: "resolve DNS once, pin the resolved IP, then send the HTTP request directly to that IP (with the Host header set to the original domain)". Many SSRF defense libraries (e.g., ssrfFilter, safe-curl) adopt this pinning pattern.

Redirect chains #

Even allowlist-based defenses (only allow specific domains) can be defeated by automatic HTTP redirect following. The attacker sets up an endpoint on their allowed domain that returns 301 Location: http://169.254.169.254/.... The server blindly follows the redirect from the initial allowed-domain response and ends up at the internal IP.

Auto-follow redirects (curl -L equivalent) should be disabled, or each redirect target should be re-validated with the same checks.

URL parser interpretation differences (Parser Confusion) #

Attacks that exploit differences in interpretation between the language's URL parser and the HTTP client's URL parser.

http://allowed.example#@evil.example/
http://allowed.example@evil.example/
http://allowed.example\\@evil.example/

One language parses allowed.example as the host (validation passes), while a different HTTP client parses evil.example as the host (the actual connection goes there). Multiple CVEs have come from this divergence between Python's urllib and Go's net/url. The defensive rule: host validation and HTTP request must use the same library.

Capital One 100M-record breach (2019) #

The inflection point that put SSRF in mainstream news. A WAF (ModSecurity-based) at Capital One running on AWS had an SSRF: the attacker ① POSTed http://169.254.169.254/latest/meta-data/iam/security-credentials/... as a URL parameter to extract the temporary IAM credentials, then ② used those credentials with AWS CLI to S3:ListBuckets → S3:GetObject and exfiltrated about 100 million credit card application records.

One root cause was excessive S3 permissions on the WAF instance. The damage wasn't from SSRF alone — IAM least-privilege violations massively amplified it. This triggered AWS to introduce IMDSv2 (described later), which requires a session token to access the metadata endpoint.

GitLab (CVE-2021-22214 and others) #

GitLab has had several SSRF issues in CI/CD and repository import features. CVE-2021-22214 allowed unauthenticated access to internal metadata endpoints; for self-hosted GitLab deployments running in the cloud, this could lead to IAM theft. GitLab responded with stronger allowlists and explicit loopback / link-local rejection.

Shopify Bug Bounty (2018–2022) #

Shopify has received many SSRF reports via HackerOne, paying up to $25,000 per finding. "Internal microservices that interpret ?url=", "URL validation bypasses on OAuth callbacks", "via image-fetching workers" — a famous example of how large-scale e-commerce platforms continuously expose SSRF crevices because the attack surface is so wide.

Microsoft Exchange (ProxyShell / SSRF + auth bypass, 2021) #

A series of Exchange vulnerabilities (CVE-2021-34473 and others) chained SSRF + authentication bypass + arbitrary file write to reach RCE. The SSRF component was used to hit the internal /autodiscover/autodiscover.json endpoint to extract other users' backend URLs. The incident scale reached tens of thousands of Exchange servers compromised worldwide, with webshells dropped indiscriminately.

Lessons #

• Cloud metadata is the attacker's top-priority target
• Restricting IAM role privileges alone cuts damage by orders of magnitude (the heart of Capital One)
• SSRF is dangerous alone, but chained with other vulnerabilities it reaches RCE-level severity (the heart of Exchange)
• When running self-hosted OSS internally (GitLab, Confluence, Jira, etc.), their SSRF is just as dangerous under the same assumptions

Like XSS, no single SSRF defense holds. Combine URL validation, IP pinning, scheme restrictions, egress filtering, IMDSv2, and IAM least privilege.

Allowlist-based URL validation — highest priority #

Blacklists (block 127.0.0.1) are bypassed. Switch to a scheme that explicitly enumerates legitimate destinations.

Key points:

• Explicitly limit schemes
• Allowlist hostnames
• Validate the final IP after DNS resolution with ipaddress (rebinding defense)
• Connect directly to the IP from validation, with only the Host: header carrying the domain (no rebind between validation and actual call)
• Forbid redirects (or re-validate redirect targets if allowed)

IMDSv2 (AWS) — authentication on the metadata endpoint #

Introduced by AWS in response to Capital One. Metadata access becomes a two-step session: PUT /latest/api/token to fetch a short-lived token, then attach X-aws-ec2-metadata-token header — no response otherwise.

If SSRF is restricted to "GET only", "no header injection", "single-hop TTL", then getting the token itself is hard — that's IMDSv2's defensive value. On EC2, disable IMDSv1 in the launch options (MetadataOptions: HttpTokens=required); this is current best practice.

Egress filtering — stop it at the way out #

Restrict the destinations your web app server can reach via firewall / NAT GW / VPC Endpoint Policy. Even if SSRF succeeds, if the network layer blocks it, internal IPs and metadata are unreachable.

• Deny 169.254.0.0/16 / 10.0.0.0/8 / 192.168.0.0/16 / 172.16.0.0/12 in the outbound rules of VPC security groups
• AWS VPC Endpoint Policy restricts "S3 from this instance is allowed only to this bucket"
• Place ECS tasks for the app in a dedicated subnet + dedicated SG that blocks metadata IP at the SG level

Scheme / port / size limits #

In the HTTP client configuration:

• Only http / https schemes (block file://, gopher://, dict://, ldap://, jar://, etc.)
• Only ports 80 / 443 (so internal service ports can't be probed)
• Disable redirect following (or re-validate the redirect target)
• Short timeouts (makes Blind SSRF timing analysis harder)
• Response size limit (also blocks resource-exhaustion via hitting heavy internal APIs)

For PHP cURL:

curl_setopt($ch, CURLOPT_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS);
curl_setopt($ch, CURLOPT_REDIR_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);

IAM least privilege — the last line of defense for limiting damage #

Even if SSRF lands and the IAM credentials are stolen, if the role can do little, the damage is small. The heart of the Capital One incident was that the WAF instance had S3:ListAllMyBuckets and S3:GetObject attached. Asking "does the WAF actually need to read S3?" would likely have prevented the disaster.

• Create dedicated IAM roles per instance / Pod
• Restrict resources (s3:GetObject only on arn:aws:s3:::myapp-uploads/*)
• Restrict actions (s3:GetObject only, not s3:*)
• For buckets holding sensitive data, use VPC Endpoint Policy + Bucket Policy as double lock

Sanitizer libraries #

Writing SSRF defenses by hand is full of traps. Use battle-tested libraries:

• Node.js: ssrf-req-filter, request-filtering-agent
• Python: safeurl-python, advocate
• Go: safehttp, safedialer
• Java: safe-url, OWASP ESAPI

These do "DNS resolution → IP classification → IP pinning → redirect re-validation" internally.

Manual testing #

Hammer every feature that takes a URL (preview / webhook / external import / OG image / PDF render / image transform) with SSRF payloads.

Burp Suite Collaborator (Blind SSRF detection) #

For Blind SSRF, the response is invisible, so OOB detection is the standard. Burp Collaborator provides an attacker-owned DNS / HTTP server and records whether the target tried to resolve / fetch a Collaborator-controlled domain.

• DNS interaction only → SSRF exists, but no HTTP is sent (only DNS resolution)
• HTTP interaction too → SSRF succeeds, arbitrary URLs can be GETed
• Neither → no SSRF at that location

Free alternatives include interactsh (Project Discovery) and canarytokens.

Static analysis #

Trace "user input → HTTP client call" data flow in source code. Semgrep / CodeQL / SonarQube have SSRF rules. Even a simple grep of framework-specific sinks (requests.get, urllib.request.urlopen, Net::HTTP.get, HttpClient.get) gives you a list of suspects.

Production monitoring #

• Monitor anomalous traffic to the metadata endpoint via VPC Flow Logs (normal traffic is bounded; sudden spikes are abnormal)
• Alert on outbound attempts to private networks in firewall / NAT GW logs
• WAF-layer rules that alert on literal strings like 169.254.169.254 in requests

SSRF is unglamorous but one of the most dangerous entry points among modern Web app vulnerabilities to watch out for. In today's stacks where cloud metadata / internal APIs / private networks live just one hop away, the moment "the server can fetch arbitrary URLs" arises, IAM theft, internal exploration, and lateral movement immediately become possible.

The simplest "take a URL and fetch it" features are precisely the ones that breed SSRF. At the design stage, remember: trust boundaries cannot be defined by IP addresses — only by explicit allowlists.