Overview
Server-Side Request Forgery (SSRF) is a web security vulnerability in which an attacker can cause the server to make HTTP (or other protocol) requests to an arbitrary destination of the attacker's choosing. Because the request originates from the server itself, it can reach internal services, cloud provider metadata endpoints, and other resources that are not exposed to the public internet. SSRF was elevated to its own dedicated category in the OWASP Top 10 2021 (A10) in recognition of its prevalence and high exploitability in modern cloud-hosted architectures.
How it works
SSRF arises when an application accepts a user-controlled value (URL, hostname, IP address, or file path) and uses it to construct a back-end HTTP request without sufficient validation. The attacker substitutes a benign target with a malicious one.
- Direct (in-band) SSRF: The server's response to the forged request is returned directly to the attacker, leaking internal content such as service banners or data from internal APIs.
- Blind (out-of-band) SSRF: The response is not reflected to the attacker, but the request is still issued. Impact is confirmed via DNS callbacks, timing differences, or side-channel observations.
- Cloud metadata endpoints: In AWS, GCP, and Azure environments, the link-local address
169.254.169.254(and equivalent IMDSv2 endpoints) serves instance credentials, IAM roles, and configuration data — a primary SSRF target. - Internal port scanning: By varying the target IP and port, an attacker can map reachable internal hosts and open ports from the server's network vantage point.
- Protocol smuggling: Some SSRF vulnerabilities can be exploited with non-HTTP schemes such as
file://,dict://,gopher://, orftp://to interact with services that do not speak HTTP. - DNS rebinding / redirect chains: Attackers bypass allowlist checks by first passing validation with a legitimate domain that later resolves to an internal IP, or by chaining open redirects.
A typical attack payload might look like: https://example.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
Business impact
Successful SSRF exploitation can have severe consequences:
- Credential theft: Retrieval of cloud IAM credentials from metadata services can lead to full cloud account compromise, enabling lateral movement and data exfiltration at scale.
- Internal network reconnaissance: Attackers map internal network topology, services, and software versions, substantially lowering the cost of follow-on attacks.
- Data exfiltration: Internal APIs, databases exposed only within the VPC, configuration stores (e.g., Consul, etcd), and secret managers may be directly queried.
- Remote code execution: SSRF against services like Redis, Memcached, or internal admin interfaces can lead to RCE via protocol abuse (e.g., Gopher-based Redis command injection).
- Compliance violations: Exposure of PII or regulated data via internal APIs triggers obligations under GDPR, HIPAA, PCI-DSS, and similar frameworks.
- Reputational and financial damage: High-profile SSRF breaches (e.g., the 2019 Capital One incident) have resulted in regulatory fines exceeding $80 million and lasting reputational harm.
How to fix it
- Validate and allowlist destinations: Maintain a strict allowlist of permitted domains, IPs, and ports. Reject any request whose resolved IP falls in private RFC 1918 ranges (
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16), loopback (127.0.0.0/8), link-local (169.254.0.0/16), or IPv6 equivalents. - Resolve DNS before validation: Perform DNS resolution server-side and validate the resulting IP address against the allowlist before issuing the request, mitigating DNS rebinding attacks. Ensure the same resolved address is used for the actual connection (TOCTOU-safe implementation).
- Disable unnecessary URL schemes: Restrict accepted URL schemes to
https://only. Explicitly rejectfile://,dict://,gopher://,ftp://, and similar schemes at the parser level. - Use a dedicated egress proxy or firewall: Route all server-initiated outbound traffic through a proxy or egress firewall that enforces destination allowlists at the network layer, providing defence-in-depth independent of application-level controls.
- Disable redirects or validate redirect destinations: If the HTTP client library follows redirects automatically, either disable redirect following or re-validate each redirect target against the allowlist.
- Enforce IMDSv2 in cloud environments: For AWS, enforce IMDSv2 (token-based metadata access) on all EC2 instances, which requires a PUT request with a custom header that SSRF payloads cannot easily satisfy.
- Apply least-privilege network segmentation: Ensure the application's runtime network identity has no unnecessary access to internal services. Use security groups, network policies, or VPC firewall rules to limit lateral reachability.
- Avoid returning raw server responses to clients: Where possible, process the fetched resource server-side and return only the necessary data to the client, reducing information leakage in partial-SSRF scenarios.
- Log and alert on anomalous outbound requests: Monitor for requests to RFC 1918 addresses, cloud metadata endpoints, or unexpected external destinations, and alert on violations.
Sensagraph automatically detects SSRF vulnerabilities, including blind variants, by probing user-controllable URL parameters and analysing server behaviour.