Server-Side Request Forgery (SSRF) — Overview

What is SSRF#

Server-Side Request Forgery (CWE-918, OWASP A10:2021) occurs when an attacker can cause a server to make HTTP requests to an arbitrary destination — internal or external. The server acts as a proxy, so requests originate from a trusted internal IP. Firewalls, security groups, and VPC routing rules that prevent external clients from reaching internal services do not block requests from the server itself.

SSRF earned its own OWASP Top 10 category in 2021 — the first new entry not seen in A09:2017. The reason: cloud-first architectures made every EC2 instance, Lambda function, GCE VM, and Azure Virtual Machine expose a link-local metadata endpoint (169.254.169.254) that is only reachable from within the instance. A single SSRF vulnerability on any application running in the cloud becomes a direct credential theft path.

SSRF differs from CSRF in a key way: CSRF targets the victim's browser and their session; SSRF targets the server and its network position. SSRF is typically more impactful because internal services often have no authentication, assuming network isolation is sufficient. OWASP A10:2021 references 385 CVEs mapped to CWE-918 and notes that while incidence rates appear low in testing, above-average exploit/impact potential puts it in the Top 10.

How SSRF Works#

The attacker identifies a parameter whose value is used in a server-side HTTP request. This could be a URL field, a webhook callback, an image upload-from-URL endpoint, or an import/fetch feature. Instead of submitting a legitimate URL, the attacker provides an internal address. The server makes the request from its own context and, in the simplest case, returns the response directly.

The critical difference from a user-side redirect: the application's outbound request bypasses all external-facing controls. A WAF inspecting inbound traffic does not inspect the application's own outbound requests to the metadata service.

SSRF Attack Variants#

Six distinct SSRF classes cover the full attack surface:

Basic In-Band SSRF#

The server fetches a URL supplied by the attacker and returns the response body directly. Any endpoint accepting a URL parameter and returning its content is a candidate. Attack surfaces include link preview endpoints, profile avatar upload-from-URL, import-from-feed functionality, and webhook test buttons that display the response.

Blind SSRF#

The server makes the outbound request but suppresses the response. Confirmation requires an external OOB listener (Burp Collaborator, Interactsh, oast.fun). The BreachVex scanner uses a graduated confidence model: a DNS-only callback is treated as potential, an HTTP callback as a confirmed high-severity finding, and data exfiltration via the out-of-band body as confirmed critical. DNS-only alone never promotes to confirmed — infrastructure components routinely resolve hostnames without making HTTP requests.

Cloud Metadata SSRF#

Every major cloud provider exposes a link-local metadata service at 169.254.169.254 (AWS, GCP, Azure, DigitalOcean) or equivalent addresses. On AWS with IMDSv1, two requests suffice to obtain temporary IAM credentials — no token, no authentication, no prior knowledge of the role name required. The 2019 Capital One breach followed exactly this pattern, exposing 106 million records.

Protocol Smuggling#

When the URL-fetching library supports schemes beyond http:// and https://, alternative protocols enable raw TCP communication with internal services. gopher:// allows injecting arbitrary bytes into a Redis connection on port 6379, writing a cron job for RCE. file:///etc/passwd reads the local filesystem. dict:// queries Memcached. These attacks do not require HTTP — the server's URL library issues the raw protocol directly.

Header-Based SSRF#

HTTP headers consumed server-side can trigger outbound requests. The X-Forwarded-Host header is processed by Angular SSR, Astro, Symfony, and Django to construct internal API URLs. Injecting X-Forwarded-Host: attacker.com causes the framework to make an HTTP request to http://attacker.com/api/config rather than the legitimate internal endpoint. CVE-2026-27739 (CVSS 9.2) demonstrates this pattern on Angular SSR.

Real-World Examples#

Capital One 2019 — A misconfigured WAF running on EC2 had SSRF. The attacker queried http://169.254.169.254/latest/meta-data/iam/security-credentials/ISRM-WAF-Role, obtained temporary AWS credentials, enumerated 700+ S3 buckets, and exfiltrated 30 GB of data. Impact: 106 million records, $80M OCC fine, $190M class action settlement. Root cause: IMDSv1 (no token required) and an overprivileged IAM role.

CVE-2025-6454 — GitLab CE/EE (CVSS 8.5) — The webhook custom header feature introduced in GitLab 16.11 allowed CRLF injection into header names. An authenticated user with Developer+ role could inject \r\n sequences to forge arbitrary HTTP headers in outbound webhook requests, enabling access to internal proxies and metadata services. Fixed in 18.1.6, 18.2.6, 18.3.2.

CVE-2025-68437 — Craft CMS GraphQL — The saveAssets mutation's _file { url } parameter fetched content from arbitrary URLs without validation. An attacker with GraphQL asset permissions could supply http://169.254.169.254/latest/meta-data/iam/security-credentials/ — the fetched credentials were saved as an asset and retrievable via the CMS API.

CVE-2022-22947 — Spring Cloud Gateway (CVSS 10.0) — SpEL expressions in route predicates created an SSRF→RCE chain. Exploited in the wild within 72 hours of public disclosure, before most organizations could patch.

Detection#

Manual Testing#

1. Identify all parameters that accept URLs, hostnames, or IP addresses — check query strings, JSON body fields (url, callback, webhook, endpoint, redirect, image, src), HTTP headers (Host, X-Forwarded-Host, Referer), and data import/export endpoints.
2. Submit https://<burp-collaborator-id>.oastify.com as the parameter value for each candidate.
3. Check the Collaborator panel for DNS lookups (2 expected) and HTTP callbacks (confirms exploitability).
4. For confirmed SSRF, attempt internal targets: http://127.0.0.1/, http://169.254.169.254/latest/meta-data/, http://localhost:3000/, http://localhost:9200/.
5. If a blocklist is present, attempt encoding bypasses: decimal (http://2130706433/), IPv6 (http://[::1]/), and redirect chain (https://302.r3dir.me/?r=http://169.254.169.254/).

Automated Detection#

Interactsh (ProjectDiscovery) provides a self-hosted OOB listener. A DNS query without HTTP follow-up suggests SSRF with HTTP egress blocked — still exploitable for internal port scanning via timing. SSRFmap automates parameter fuzzing. Nuclei has SSRF templates covering cloud metadata endpoints and known vulnerable parameter names from a corpus of 80+ canonical names (url, webhook, callback, image_url, avatar_url, redirect_uri, etc.).

BreachVex detects SSRF through multiple complementary techniques: per-parameter out-of-band callback injection with a graduated confidence model, differential response analysis against RFC 5737 control IPs, and direct probing of common internal services — cloud metadata endpoints, container and orchestration APIs, monitoring dashboards, and internal datastores — using marker-based confirmation.

Prevention#

Allowlist URL Validation (Primary Defense)#

Blocklists are bypassed by encoding, DNS aliases, and IPv6 mapping. Only allowlists work:

import ipaddress
import socket
import urllib.parse
 
ALLOWED_HOSTS = frozenset({"api.stripe.com", "hooks.slack.com"})
 
def validate_url(url: str) -> bool:
    parsed = urllib.parse.urlparse(url)
 
    # 1. Scheme allowlist — blocks gopher://, file://, dict://, ftp://
    if parsed.scheme not in ("http", "https"):
        return False
 
    host = (parsed.hostname or "").rstrip(".")  # strip trailing FQDN dot (CVE-2025-62718 class)
    if not host or host not in ALLOWED_HOSTS:
        return False
 
    # 2. Resolve DNS and validate the resulting IP — defeats DNS aliases and nip.io
    try:
        results = socket.getaddrinfo(host, None, proto=socket.IPPROTO_TCP)
        for (_, _, _, _, sockaddr) in results:
            ip = ipaddress.ip_address(sockaddr[0])
            # Normalize IPv6-mapped IPv4 (::ffff:127.0.0.1 → 127.0.0.1)
            if isinstance(ip, ipaddress.IPv6Address) and ip.ipv4_mapped:
                ip = ip.ipv4_mapped
            if ip.is_private or ip.is_loopback or ip.is_link_local or ip.is_reserved:
                return False
    except (socket.gaierror, ValueError):
        return False  # fail-closed on resolution errors
 
    return True

IMDSv2 Enforcement (Cloud)#

Enforce IMDSv2 at the infrastructure level — application-level fixes are insufficient if the metadata endpoint is accessible:

# Per instance
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1
 
# Verify compliance across account
aws ec2 describe-instances \
  --query "Reservations[].Instances[?MetadataOptions.HttpTokens=='optional'].{ID:InstanceId}" \
  --output table
 
# Organization-wide SCP — block launching instances with IMDSv1
{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Condition": {
    "StringEquals": { "ec2:MetadataHttpTokens": "optional" }
  }
}

Network Egress Filtering#

Application-level validation should be a last resort, not the only control. Restrict egress at the network layer:

• Block 169.254.169.254/32 and 168.63.129.16/32 in security group outbound rules
• Implement egress-only internet gateways; deny all outbound traffic by default
• In Kubernetes, use CNI network policies to block pod-to-metadata-service traffic
• Drop CAP_NET_RAW in container security contexts

SSRF vs CSRF#

Resources#

• OWASP A10:2021 — SSRF
• OWASP SSRF Prevention Cheat Sheet
• PortSwigger Web Security Academy — SSRF
• NIST NVD — CWE-918