SSRF (Server-Side Request Forgery): Detection, Impact & Prevention

Server-Side Request Forgery (SSRF) vulnerabilities emerge whenever an application feature accepts a destination URL from an untrusted client and executes an outbound network request using server-side privileges. Typical vulnerable components include custom webhook notification dispatchers, PDF invoice generators that render remote stylesheets, social media link preview crawlers, profile avatar import tools, and data synchronization proxies. Because the outgoing request originates from the application server's trusted IP address inside the corporate VPC, perimeter firewalls and security groups treat the traffic as internal and authorized, effectively transforming the application server into an unintended proxy for the attacker.

In modern cloud infrastructure (AWS EC2, Google Cloud Compute Engine, Microsoft Azure Virtual Machines), SSRF represents a catastrophic threat vector. By default, cloud hypervisors expose a link-local metadata IP address (169.254.169.254) accessible from any process running on the host instance. Under legacy implementations like AWS IMDSv1, this endpoint requires zero authentication. An attacker who supplies http://169.254.169.254/latest/meta-data/iam/security-credentials/ into a vulnerable URL parameter can extract the temporary IAM role credentials (AccessKeyId, SecretAccessKey, and Token) assigned to the cloud instance. With these credentials in hand, the attacker can connect directly to the cloud provider's management APIs from their external machine, granting them full administrative control over internal S3 buckets, RDS databases, and serverless Lambda functions.

Beyond cloud metadata exploitation, SSRF enables adversaries to map internal networks and interact with unauthenticated administrative microservices. Threat actors routinely target internal database instances such as Redis (port 6379), Memcached (port 11211), Elasticsearch (port 9200), and Apache Solr (port 8983). By crafting specialized payloads or leveraging protocols like gopher://, attackers can issue arbitrary write commands to internal key-value stores, overwrite serialized application sessions, or trigger secondary Remote Code Execution (RCE) vulnerabilities. Even in Blind SSRF scenarios - where the server fetches the target URL but does not return the response body to the user - adversaries measure network connection latency to perform internal port scanning and discover hidden internal services.

Audit your public web applications and API endpoints against cloud metadata exfiltration using the WeSecureX Website Vulnerability Scanner and inspect perimeter assets on Attack Surface Reconnaissance. Check our technical breakdown of Common Website Vulnerabilities and How to Prevent Them.

Attempting to defend against SSRF by validating user-supplied URLs using regular expressions alone is fundamentally insecure. Attackers bypass string-based filters using alternative IP encodings - such as decimal integers (http://2130706433 for 127.0.0.1), hexadecimal notation (http://0x7f000001), octal values (0177.0.0.1), or enclosed alphanumeric Unicode homoglyphs. A regex that looks for 127.0.0.1 or localhost will trivially pass these obfuscated strings, allowing the underlying HTTP client library to resolve the address and trigger an internal request.

A far more dangerous bypass technique is DNS Rebinding, which exploits a classic Time-of-Check to Time-of-Use (TOCTOU) race condition. In a DNS rebinding attack, an attacker registers a custom domain name (such as attacker-domain.com) configured with a custom DNS nameserver that serves responses with a Time-to-Live (TTL) of 0 seconds. When the application server executes its validation logic, it performs a DNS lookup; the nameserver responds with a legitimate public IP address (such as 93.184.216.34). Because the IP is public, the validation check passes. However, a few milliseconds later, when the application's HTTP client opens a TCP socket to execute the request, the socket library performs a second DNS query because the TTL has expired. At this instant, the attacker's nameserver responds with 169.254.169.254 or 127.0.0.1, coercing the server into connecting directly to the restricted internal metadata endpoint.

To build an impenetrable SSRF defense, engineering teams must implement a two-phase socket pinning architecture:

1. Strict Protocol Allowlisting: Permit only https: (or http: if explicitly necessary). Disallow dangerous URI schemes such as file://, gopher://, dict://, and ftp://.
2. Authoritative DNS Resolution: Perform asynchronous DNS lookups using the host operating system's DNS resolver to extract all associated IPv4 and IPv6 addresses.
3. CIDR Subnet Validation: Verify that none of the resolved IP addresses fall within RFC 1918 private address spaces (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback ranges (127.0.0.0/8, ::1), link-local metadata space (169.254.0.0/16, fe80::/10), or multicast blocks.
4. Transport Socket Pinning: Pass the pre-validated IP address directly into the HTTP client socket options (or custom agent lookup function) to ensure that the outgoing TCP connection connects exclusively to the verified IP without performing a second DNS query.

Verify your DNS records and network configuration with the WeSecureX DNS Record Lookup and test exposed services using the Open Port Scanner.

Application-level URL validation must be reinforced with robust infrastructure network boundaries. If a software defect or third-party dependency vulnerability bypasses application filters, defensive network controls provide an impassable backstop. A defense-in-depth security model ensures that even if an attacker manages to trigger an arbitrary HTTP request, the network architecture prevents unauthorized egress and metadata exfiltration.

The cornerstone of modern cloud metadata defense is enforcing AWS IMDSv2 across all virtual machines and container instances. Unlike IMDSv1, which accepts simple unauthenticated GET requests, IMDSv2 is a session-oriented protocol that requires callers to first issue an HTTP PUT request with an X-aws-ec2-metadata-token-ttl-seconds header to acquire a temporary cryptographic session token. Subsequent metadata queries must include this token in an X-aws-ec2-metadata-token header. Because most SSRF vulnerabilities are restricted to standard GET or POST verbs and cannot forge custom PUT headers across cross-origin boundaries, IMDSv2 completely neutralizes metadata exfiltration. Furthermore, setting HttpPutResponseHopLimit to 1 ensures that containerized applications (such as Docker or Kubernetes pods running on EC2) cannot access the host instance's metadata endpoint.

In addition to IMDSv2, enterprise architectures must enforce strict egress firewall controls and network segmentation. Application servers residing in private subnets should have no direct route to the public internet or link-local subnets; outbound internet connectivity should be mediated through forward proxies or NAT Gateways with strict domain allowlists. Webhook dispatchers and URL crawlers should be isolated into dedicated, ephemeral worker containers operating inside isolated DMZ subnets that have zero network connectivity to internal database clusters, Redis caches, or management planes.

Finally, server-side HTTP fetch clients must be configured to disable automatic HTTP redirect following (setting redirect: 'manual' or maxRedirects: 0). If an application validates that an initial URL (such as https://example.com) points to a legitimate public IP, but automatically follows HTTP 301 or 302 redirects, an attacker can configure the external server to issue a redirect toward http://169.254.169.254. Unless redirect destinations are recursively validated against private IP allowlists, the application will follow the redirect directly into internal infrastructure.

Audit your HTTP headers with the Security Headers Checker and learn how continuous testing protects modern applications in Securing Modern Web Applications: The Shift to Continuous Testing.