Server-Side Request Forgery (SSRF) is deceptively simple: the attacker tricks your server into making HTTP requests to destinations it shouldn't reach. But the impact is profound. Your server sits inside your network perimeter, behind firewalls, with access to internal services, cloud metadata endpoints, and private APIs. An SSRF vulnerability turns your own infrastructure into the attacker's proxy into your private network.
How SSRF Occurs
SSRF appears wherever an application makes server-side HTTP requests based on user input. Common patterns include:
- URL preview/unfurling features (paste a link, get a preview)
- Webhook delivery systems (user specifies a callback URL)
- PDF generation from user-provided URLs
- Image download and processing from external URLs
- API integrations that fetch data from user-configured endpoints
In each case, the application takes a URL from the user and fetches it server-side. If the URL isn't properly validated, the attacker can point it at internal resources.
The Cloud Metadata Goldmine
The most devastating SSRF target in cloud environments is the instance metadata service, typically available at http://169.254.169.254. This internal-only endpoint provides:
- Temporary IAM credentials with whatever permissions the instance has
- Instance identity documents
- Network configuration details
- User data scripts (which often contain secrets)
// Attacker's SSRF payload
https://yourapp.com/api/fetch-url?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
// Server fetches its own IAM credentials and returns them to the attacker
This is exactly how the Capital One breach worked. SSRF to the metadata service yielded AWS credentials that provided access to 100 million customer records.
Internal Service Discovery
Beyond cloud metadata, SSRF enables reconnaissance of internal networks that are completely invisible from the outside:
- Port scanning: By observing response times and error messages, attackers map internal services and open ports.
- Internal API access: Services that trust internal network requests without authentication become fully accessible.
- Database interfaces: Redis, Memcached, and other services that listen on internal ports without authentication can be accessed and manipulated through protocol-specific SSRF payloads.
- Admin panels: Internal dashboards, monitoring tools, and management interfaces that assume network-level access control.
Bypass Techniques
Naive SSRF protections — URL blocklists, IP address checks — are routinely bypassed. Attackers use:
- DNS rebinding: The URL resolves to an allowed IP during validation but resolves to an internal IP when the actual request is made.
- Alternative IP representations:
169.254.169.254can be written as0xA9FEA9FE,2852039166, or169.254.169.254.nip.io. - Redirect chains: The URL points to an attacker-controlled server that returns a 302 redirect to the internal target.
- Protocol smuggling: Using
gopher://,file://, ordict://protocols to interact with internal services in ways HTTP-only filters don't anticipate.
SSRF in Modern Architectures
Microservice architectures amplify SSRF risk. Services communicate over HTTP, trust internal network requests, and each service is an SSRF target with its own set of accessible internal resources. A single SSRF vulnerability in a frontend service can cascade through the entire internal service mesh.
The External Signal
While SSRF is an application vulnerability, the damage it causes depends on the broader infrastructure: Are cloud metadata services protected with IMDSv2? Do internal services require authentication? Is the network segmented to limit what's reachable? The external configuration of your domain — security headers, TLS hardening, information disclosure — reflects the same security maturity that determines SSRF resilience.
ShieldReport identifies the external security signals that correlate with SSRF exposure — information disclosure, server version leakage, and configuration weaknesses — giving you insight into the surface area that attackers use to select SSRF targets.