What is server-side request forgery?

Many applications include features that fetch URLs the user supplies: import an image from a URL, generate a preview of a link the user pasted, validate a webhook target, render a PDF from a URL.

In each case, the application's server makes an outbound HTTP request to the URL. If the application does not strictly validate where that URL points, the attacker can supply an internal URL instead. The application reaches into its own network on the attacker's behalf, and the attacker reads the response.

The internal targets that matter most: cloud instance metadata endpoints (which return temporary credentials), internal admin interfaces that are firewalled off from the public internet, and other services on the same VPC that trust requests from inside the network.

In 2019, an attacker exploited a misconfigured web application firewall in front of Capital One's AWS environment to perform SSRF against the EC2 instance metadata endpoint at 169.254.169.254. The metadata service returned temporary IAM credentials, which the attacker used to read approximately 100 million customer records from S3. The settlement reached $190 million.

This chain (SSRF -> metadata -> credentials -> data) is one of the most common cloud-era exploit patterns. AWS introduced IMDSv2 specifically to defend against it. Many production AWS environments still permit IMDSv1 on at least some instances.

• Steal cloud credentials. Hit the metadata endpoint (169.254.169.254 on AWS, 169.254.169.254 on Azure, metadata.google.internal on GCP), get the temporary credentials assigned to the instance, use them against the cloud provider's API.
• Scan and exploit internal services. Enumerate internal hostnames and ports, find admin interfaces, exploit them directly.
• Bypass authentication. Some internal services trust requests that come from inside the network without authentication. SSRF turns the application server into an authentication bypass.
• Pivot into databases and caches. Read or write to internal Redis, Memcached, Elasticsearch instances that were never meant to be exposed.
• Data exfiltration. Use the SSRF response to leak data the application normally would not return to the user.

Defense in three layers:

• URL allowlist. The application should only fetch URLs that match an explicit allowlist of hosts. Block everything else by default. Validate after DNS resolution, not just on the input string, to catch DNS-rebinding tricks.
• Network-level controls. The application server should not be able to reach the metadata endpoint or internal admin services at all. Egress firewalls, network segmentation, and IMDSv2 (which requires a session token, defeating basic SSRF) close most of the post-exploitation paths.
• Response handling. Do not return the raw response of the fetched URL to the user. Return a status or a transformed value. Limits how much the attacker can read even when the fetch succeeds.
• Disable response redirects. Most SSRF libraries follow HTTP redirects by default. An allowlist that accepts only https://images.example.com is bypassed by a redirect to the metadata endpoint.

Every application engagement maps the places the server makes outbound HTTP requests on the user's behalf. For each one we test:

• Direct SSRF. Can we point the fetch at an internal hostname or IP?
• Metadata-endpoint reachability. Can we reach the cloud metadata service, and does it return credentials?
• DNS-rebinding bypass. Can we register a hostname that resolves to a public IP at validation time and an internal IP at fetch time?
• Redirect-based bypass. Can we redirect from an allowlisted host to an internal target?
• Blind SSRF. When the response is not returned to us, can we still confirm the request fired (via timing, DNS callback, or out-of-band) and reach an internal target?

Deliverable includes the realistic blast radius for each finding: what internal service is reachable, what credentials are extractable, what data is at risk.