Server-Side Request Forgery earned its place on the OWASP Top 10 in 2021, and the reason is cloud infrastructure. SSRF has existed for years, but in traditional on-premises environments, the impact was limited. In cloud environments, SSRF often provides direct access to instance metadata services, which hand out temporary IAM credentials. That single step can escalate from "I can make your server fetch a URL" to "I have administrative access to your AWS account."
The Capital One breach in 2019, which exposed over 100 million customer records, was enabled by SSRF through a misconfigured WAF. The attacker accessed the EC2 metadata service and obtained IAM credentials with S3 access. That should tell you everything about how seriously to take this vulnerability.
How SSRF Works
Any application feature that fetches a resource from a URL the user can influence is a potential SSRF vector. Common examples:
- URL preview/unfurl. Chat applications and social media platforms that fetch page titles and thumbnails from user-provided URLs.
- Webhook delivery. Applications that send HTTP callbacks to user-specified endpoints.
- PDF generation. Services that convert HTML (potentially containing external references) to PDF.
- Image processing. Applications that fetch and resize images from user-provided URLs.
- API proxying. Backend-for-frontend patterns where the server fetches data from URLs derived from client input.
- Import/export. Features that import data from a URL (CSV import, RSS feed ingestion).
In each case, the server makes an HTTP request to a URL the attacker controls or influences. The attacker changes the URL to point at an internal resource.
The Cloud Metadata Goldmine
Cloud instance metadata services run on a well-known, non-routable IP address:
- AWS:
http://169.254.169.254/latest/meta-data/ - GCP:
http://metadata.google.internal/computeMetadata/v1/ - Azure:
http://169.254.169.254/metadata/instance
These services provide instance information, network configuration, and most critically, temporary security credentials for the instance's IAM role.
An SSRF that can reach http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name] returns an access key, secret key, and session token. With those credentials, the attacker can access any AWS service the instance role permits — S3 buckets, DynamoDB tables, SQS queues, Lambda functions.
AWS IMDSv2 mitigates this by requiring a token obtained through a PUT request before metadata is accessible. If your SSRF only allows GET requests, IMDSv2 blocks it. But not all SSRF vectors are limited to GET requests, and not all cloud providers have equivalent protections.
SSRF Attack Techniques
Attackers have developed numerous techniques to bypass basic SSRF protections.
IP address representations. 127.0.0.1 can be written as 2130706433 (decimal), 0x7f000001 (hexadecimal), 017700000001 (octal), or 127.1 (abbreviated). Blocklists that only check the standard dotted-decimal notation miss these.
DNS rebinding. The attacker's DNS server returns a public IP on the first lookup (passing validation) and an internal IP on subsequent lookups (reaching the internal service). The application validates the hostname, resolves it, validates the IP, but then resolves it again for the actual request — and gets a different answer.
URL parsing inconsistencies. Different URL parsing libraries handle edge cases differently. http://attacker.com@internal-server/ might be parsed as attacker.com by the validator but internal-server by the HTTP client. The @ character, backslashes, fragment identifiers, and encoded characters all create confusion between parsers.
Redirect chains. The attacker's server responds with a 302 redirect to an internal URL. If the HTTP client follows redirects (which most do by default), the request reaches the internal service.
Protocol smuggling. Some HTTP libraries support non-HTTP protocols. gopher://, file://, dict:// can be used to interact with internal services that are not HTTP.
Prevention Strategies
Input validation (necessary but insufficient). Validate that user-provided URLs use http or https schemes only. Reject file://, gopher://, ftp://, and others. Validate that the hostname resolves to a public IP address. But do this validation on the resolved IP, not the hostname, to prevent DNS rebinding.
Network-level controls (strongest defense). Run URL-fetching services in a network segment that cannot reach internal services or cloud metadata endpoints. Use firewall rules to block access to 169.254.169.254 from application servers. This is the most reliable defense because it does not depend on parsing URLs correctly.
IMDSv2 (AWS-specific). Enable IMDSv2 and set the hop limit to 1. This prevents the metadata service from responding to requests that traverse a network hop (like those from a container or a proxied request).
Disable redirects. Configure HTTP clients to not follow redirects when fetching user-provided URLs. Or validate the redirect target before following it.
Response filtering. Do not return the raw response body to the user. Parse the expected content (extract the page title, resize the image) and return only the processed result. This prevents data exfiltration through SSRF even if the request reaches an internal service.
Dedicated URL-fetching service. Isolate URL fetching into a separate service with its own network context and limited permissions. This service has no access to internal resources, so even if SSRF occurs, the attacker reaches nothing of value.
SSRF in Specific Technologies
Webhooks. When users configure webhook URLs, validate the URL at configuration time and at delivery time. URLs that were public when configured can resolve to internal IPs later (DNS rebinding). Send webhooks from a network segment that cannot reach internal services.
GraphQL. GraphQL introspection queries can reveal internal schema details. More importantly, GraphQL's flexible query structure can sometimes be abused to trigger server-side fetches.
Server-side rendering. SSR frameworks that render HTML to generate PDFs or images often process external resources (stylesheets, images, fonts). These are SSRF vectors if the HTML content is user-controlled.
CI/CD pipelines. Build systems that fetch dependencies from user-specified URLs are SSRF targets. A malicious package.json with a dependency pointing to an internal URL can exfiltrate data during npm install.
Testing for SSRF
Manual testing. Submit internal URLs (http://127.0.0.1, http://169.254.169.254/) wherever the application accepts URLs. Use an out-of-band server (Burp Collaborator, interactsh) to detect blind SSRF where the response is not returned.
Bypass testing. If basic internal URLs are blocked, try the bypass techniques: alternate IP representations, DNS rebinding, URL parsing tricks, and redirect chains.
Automated scanning. DAST tools test for SSRF, but their coverage is limited to URL parameters they can identify. Manual testing remains essential for finding SSRF in less obvious locations.
Real-World Impact
Beyond cloud metadata theft, SSRF enables:
- Port scanning of internal networks through timing and error analysis
- Accessing internal APIs that lack authentication because they are "internal only"
- Reading local files via
file://protocol if the HTTP client supports it - Remote code execution through interaction with internal services (Redis, Memcached) via protocol smuggling
How Safeguard.sh Helps
Safeguard.sh monitors the HTTP client libraries and URL parsing libraries in your dependency tree for known SSRF-related vulnerabilities. When a library you depend on has a vulnerability that enables redirect-following to internal addresses or URL parsing inconsistencies that bypass SSRF protections, Safeguard.sh alerts you with the specific CVE and affected component. The platform's SBOM tracking ensures you know exactly which applications use which HTTP client versions, so you can prioritize updates for the components most exposed to SSRF risk.