What is Server-Side Request Forgery (SSRF)?

Server-Side Request Forgery (SSRF) is a web security vulnerability that lets an attacker trick a server into making HTTP requests to unintended destinations. Instead of attacking the server directly, the attacker uses it as a proxy, reaching internal services, cloud metadata endpoints, and private networks that are invisible from the public internet. SSRF turns a trusted server into a weapon aimed inward at its own infrastructure.

How SSRF Works

Many web applications fetch resources from URLs that users supply. An image preview tool might download a picture from a user-provided link. A webhook system might POST data to a user-configured endpoint. A PDF generator might render HTML fetched from a URL. In each case, the server is the one making the outbound HTTP request.

The vulnerability arises when the application does not validate which URLs the server is allowed to request. An attacker can replace the intended URL with one pointing to internal infrastructure:

// Normal usage - user provides a public URL
GET /api/preview?url=https://example.com/image.png

// SSRF attack - attacker targets internal metadata
GET /api/preview?url=http://169.254.169.254/latest/meta-data/

The server, which sits inside the private network and has access to internal resources, dutifully fetches the requested URL and returns the result. The attacker never connects to the internal service directly -- the server does it on their behalf.

The key insight is the trust boundary. Firewalls and security groups are configured to block external traffic from reaching internal services. But the web server is already inside the trusted zone. SSRF exploits this position: the server's requests pass through security boundaries because the server is trusted.

Attack Targets

SSRF is dangerous because of what lives inside private networks. The most commonly targeted resources fall into a few categories.

Cloud Metadata Endpoints

Every major cloud provider exposes an instance metadata service at a link-local IP address -- 169.254.169.254. This service is only reachable from the virtual machine itself and returns sensitive information: temporary access credentials, instance identity tokens, network configuration, and user data scripts that often contain secrets.

# AWS metadata endpoint
http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name

# GCP metadata endpoint
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Azure metadata endpoint
http://169.254.169.254/metadata/identity/oauth2/token

An SSRF vulnerability that can reach 169.254.169.254 often yields IAM credentials with permissions to access S3 buckets, databases, or other cloud services. This turns a single web vulnerability into full cloud account compromise.

Internal Services and Databases

Most applications run alongside internal services that are never exposed to the internet: databases on 10.0.0.0/8 or 172.16.0.0/12 private address space, internal APIs, admin panels, monitoring dashboards, and message queues. SSRF can reach any service that the vulnerable server can connect to over the network.

Localhost Services

Services bound to 127.0.0.1 (localhost) are especially dangerous SSRF targets because they often run without authentication, assuming that only local processes can connect. Admin interfaces, debug endpoints, health-check APIs, and management consoles frequently listen only on localhost. An SSRF pointing at http://127.0.0.1:8080/admin or http://[::1]:9090/metrics can reach these services as if the attacker were on the machine itself.

Internal Port Scanning

Even when the SSRF response is not returned to the attacker, timing differences can reveal which internal ports are open. A request to an open port responds quickly; a closed port produces a connection-refused error after a shorter delay; a filtered port or non-existent host times out. By sweeping through subnets and ports, an attacker can map the internal network topology without ever being inside the network.

Types of SSRF

SSRF vulnerabilities differ in how much information they return to the attacker. The type determines what is exploitable and how difficult detection becomes.

Basic SSRF (Full Read)

The most dangerous variant. The application fetches the attacker-controlled URL and returns the response body directly. If the attacker points it at http://169.254.169.254/latest/meta-data/, the full metadata response comes back in the HTTP response. This gives the attacker complete read access to any HTTP service reachable from the server.

Blind SSRF

The server makes the request but does not return the response to the attacker. The attacker cannot read the data directly, but can still cause harm. Blind SSRF enables:

• Out-of-band data exfiltration -- the attacker points the SSRF at their own server and extracts information via DNS lookups or HTTP callback URLs
• Port scanning -- timing differences between open, closed, and filtered ports leak network topology
• Triggering actions -- hitting internal API endpoints that perform destructive operations (DELETE, restart, shutdown) without needing to see the response

Partial SSRF

The application returns some but not all of the response. It might only reveal the HTTP status code, certain headers, or a truncated portion of the body. This limits the attacker's read capability but often still enables service discovery and metadata extraction through error messages.

Case Study: The 2019 Capital One Breach

The Capital One breach is the most significant real-world SSRF attack. In 2019, an attacker exploited an SSRF vulnerability in a misconfigured WAF (Web Application Firewall) running on AWS (AS16509) to steal data belonging to over 100 million customers.

The attack chain was straightforward:

1. The attacker found an SSRF vulnerability in a WAF that Capital One used to protect its web applications.
2. Through the SSRF, the attacker made a request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ -- the AWS metadata endpoint.
3. The metadata endpoint returned temporary IAM credentials associated with the EC2 instance's role.
4. Those credentials had permissions to list and read S3 buckets. The attacker used them to download 700+ S3 buckets containing customer data: names, addresses, credit scores, Social Security numbers, and bank account numbers.
5. Capital One incurred over $300 million in costs. The attacker was convicted in 2022.

This breach directly motivated AWS to develop IMDSv2, a hardened version of the metadata service that requires session tokens and blocks SSRF-style requests (covered in the defenses section below).

SSRF via DNS Rebinding

Some applications defend against SSRF by resolving the URL's hostname and checking that the resulting IP address is not internal (not in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 169.254.0.0/16). DNS rebinding bypasses this check.

The attack works as follows: the attacker controls a domain (say, evil.com) and its authoritative DNS server. When the application resolves evil.com to check the IP, the DNS server returns a legitimate public IP like 93.184.216.34. The validation passes. But the DNS record has a TTL of zero, so when the application makes the actual HTTP request moments later, it resolves evil.com again. This time, the attacker's DNS server returns 169.254.169.254 -- and the request goes to the metadata endpoint.

DNS rebinding defeats any SSRF defense that validates the hostname at resolution time but then re-resolves it for the actual connection. The fix is to resolve the hostname exactly once and use the resulting IP for both validation and the connection -- or to block internal IPs at the network level.

Protocol Smuggling

SSRF is not limited to HTTP. If the vulnerable application's HTTP client supports other URL schemes, the attacker may be able to use protocols beyond HTTP to interact with internal services.

• file:///etc/passwd -- read local files from the server's filesystem
• gopher:// -- the Gopher protocol allows sending arbitrary bytes to a TCP socket, enabling protocol smuggling against Redis, Memcached, SMTP, and other text-based protocols
• dict:// -- the DICT protocol can also be abused to send commands to internal services
• ftp:// -- interact with internal FTP servers

Gopher-based SSRF is particularly dangerous. Because the Gopher protocol transmits raw bytes, an attacker can craft a URL that sends valid Redis commands, SMTP emails, or SQL queries to internal services that speak text-based protocols over TCP. A single gopher:// URL can execute SET and CONFIG commands against an unauthenticated Redis server, potentially writing a webshell to disk or modifying application data.

This is why disabling unnecessary URL schemes is a critical defense -- most applications only need http:// and https://.

SSRF and Network Boundaries

SSRF is fundamentally a network boundary violation. Organizations design their networks with layers of isolation: public-facing servers in a DMZ, application servers in a private subnet, databases in an even more restricted subnet, and cloud metadata available only to the VM itself. Firewalls and CIDR-based security groups enforce these boundaries.

SSRF bypasses all of this. The web server is positioned inside the trusted zone by design -- it needs to reach databases, caches, and APIs. When an attacker controls where the server makes requests, they inherit the server's network position. They can reach every service the server can reach, subject only to protocol and authentication constraints.

This is why SSRF is consistently ranked in the OWASP Top 10 (added explicitly in 2021). It is not just a data-read vulnerability -- it is a network access vulnerability that collapses the distinction between external and internal.

Defenses Against SSRF

Effective SSRF defense requires multiple layers. No single control is sufficient because attackers have repeatedly found bypasses for individual measures.

1. URL Allowlists

The strongest application-level defense. Instead of trying to block dangerous URLs (a blocklist), define exactly which destinations the application is allowed to request. If the application only needs to fetch images from a specific CDN, the allowlist should contain only that CDN's domain. Everything else is denied by default.

Allowlists should operate on the resolved IP address, not just the hostname, to prevent DNS rebinding. Resolve the hostname once, validate the IP, and connect to that specific IP.

2. Block Internal IP Ranges

If a strict allowlist is not feasible, at minimum block requests to known internal and reserved IP ranges:

• 10.0.0.0/8 -- RFC 1918 private
• 172.16.0.0/12 -- RFC 1918 private
• 192.168.0.0/16 -- RFC 1918 private
• 169.254.0.0/16 -- link-local (cloud metadata)
• 127.0.0.0/8 -- loopback
• ::1/128 -- IPv6 loopback
• fc00::/7 -- IPv6 unique local
• fe80::/10 -- IPv6 link-local

This must be enforced after DNS resolution (on the resolved IP, not the hostname) and must handle edge cases: decimal IP encoding (http://2852039166/ for 169.254.169.254), IPv6-mapped IPv4 (::ffff:169.254.169.254), and URL encoding.

3. Disable Unnecessary Protocols

Configure the HTTP client to only support http:// and https:// schemes. Disable file://, gopher://, dict://, ftp://, and any other scheme. Most HTTP client libraries allow restricting the URL scheme.

4. Network Segmentation

Even if the application is vulnerable, network-level controls can limit the blast radius. Place web servers in a subnet with security group rules that only allow outbound connections to the specific internal services they need. Block the metadata IP (169.254.169.254) at the network level for instances that do not need it. Use separate VPCs or network namespaces for different trust levels.

5. IMDSv2 (AWS Instance Metadata Service v2)

After the Capital One breach, AWS introduced IMDSv2 as a direct defense against SSRF-based metadata theft. IMDSv2 requires a two-step process:

1. First, send a PUT request with a custom header (X-aws-ec2-metadata-token-ttl-seconds) to get a session token. PUT requests with custom headers cannot be made through most SSRF vulnerabilities, which typically only allow GET requests.
2. Then, include that token in subsequent GET requests to the metadata service.

IMDSv2 can be enforced at the instance level, preventing any fallback to the vulnerable v1 endpoint. GCP and Azure have implemented similar protections: GCP requires a Metadata-Flavor: Google header, and Azure requires a Metadata: true header.

6. Least-Privilege IAM

Even if an attacker obtains credentials via SSRF, the damage is limited by the permissions attached to those credentials. An EC2 instance role that only allows reading from a specific S3 bucket cannot be used to access DynamoDB or other services. Assign the minimum permissions necessary -- not broad administrative roles.

SSRF, DNS, and the Network Stack

SSRF intersects with many layers of the network stack that make the internet function. The attack relies on DNS resolution to convert hostnames to IPs, and DNS rebinding exploits the mismatch between resolution time and connection time. The targets of SSRF sit on private IP addresses that are not routable on the public internet -- addresses in RFC 1918 space that never appear in the BGP routing table.

Understanding subnetting and CIDR notation is essential for configuring SSRF defenses: every blocked IP range is a CIDR block, and misconfiguring a block (forgetting IPv6, missing a reserved range) can leave a gap. The connection between SSRF and TLS/HTTPS is also relevant -- SSRF that targets HTTPS endpoints may fail due to certificate validation, but attackers often find that internal services use plain HTTP, making them easier targets.

Detecting SSRF Attempts

Organizations can detect SSRF attacks through several signals:

• Outbound connection monitoring -- alert when application servers connect to unexpected internal IPs or the metadata endpoint
• DNS query logging -- watch for resolutions of suspicious domains that resolve to internal IPs
• Cloud audit logs -- monitor for metadata API calls and credential usage patterns that indicate stolen credentials
• WAF rules -- detect common SSRF payloads in request parameters (169.254, 127.0.0.1, localhost, file://, gopher://)

The challenge is that SSRF requests originate from the application server itself, so they look like normal outbound traffic. Behavioral analysis -- detecting anomalous connection patterns -- is often more effective than signature-based detection.

Look Up Your Infrastructure

Understanding your network's routing and addressing is the first step in defending against SSRF. Use the looking glass to explore how your public-facing infrastructure is routed, and verify the BGP origins of the networks you depend on:

• AS16509 -- AWS: see the prefixes where EC2 instances live
• AS15169 -- Google Cloud's network
• AS8075 -- Microsoft Azure's network
• Search any IP or ASN -- look up your own infrastructure