ShieldReport
HomeWhat We CheckToolsWikiCompareRoadmapPricingBlogSign InRun Free Scan
Run Scan
HomeWhat We CheckToolsWikiCompareRoadmapPricingBlogSign In
20 January 20268 min read

SSRF Exploitation: Turning Your Server Into an Attack Proxy

Server-Side Request Forgery lets attackers use your server to reach internal systems, cloud metadata services, and private networks. Explore how SSRF works and why it's devastatingly effective.

SSRFcloud securityinternal networkmetadata serviceweb attacks

Implementation Example

Use this as your remediation starting point

This animated snippet mirrors the style of fixes used in generated reports.

typescript

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.254 can be written as 0xA9FEA9FE, 2852039166, or 169.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://, or dict:// 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.

Related Reads

8 min read

Cloud Misconfigurations: The $190 Million Mistake You Might Be Making

6 min read

ShieldReport Is Free During Launch — Here's What You Get

5 min read

How to Run a Free Website Security Scan in 60 Seconds

Run Your Own Audit

Generate a developer-ready security report in under two minutes.

Try Free ScanView Sample Report
ShieldReport

Website security scanning and reporting for developers, teams, and agencies.

ShieldReport - Security reports done in minutes which developers understand | Product Hunt

Product

  • Free Security Scan
  • What We Check
  • Pricing
  • Sample Report

Resources

  • Security Blog
  • FAQ
  • Website Security Checklist
  • CSP Guide

Topics

  • Security Headers
  • TLS Configuration
  • OWASP Top 10
  • Vulnerability Scanning

© 2026 ShieldReport. All rights reserved.

Run Free ScanPricingBlogSitemapRSS Feed