What is Server-Side Request Forgery (SSRF)?
SSRF is an attack where an attacker causes a server to make requests to unintended targets, enabling access to internal services, cloud metadata, and restricted network resources.
- 1.Definition
- 2.How SSRF Works
- 3.What Attackers Can Reach via SSRF
- 4.Prevention
- 5.SSRF and Autonomous Code Governance
Definition
Server-side request forgery (SSRF) is a vulnerability where an attacker can cause a server to make HTTP or network requests to an attacker-specified destination. The server acts as a proxy: the attacker cannot directly reach the target (it may be an internal network, a cloud metadata service, or a restricted API), but the server can — and the attacker causes it to fetch and potentially return the response.
SSRF entered the OWASP Top 10 for the first time in 2021, reflecting its growing prevalence in cloud-native architectures where every application server has access to a rich internal network and cloud metadata APIs.
How SSRF Works
SSRF occurs when an application accepts a URL or hostname as input and fetches that URL server-side without validating the destination. Common vulnerable patterns:
- URL preview / link unfurling features that fetch user-provided URLs
- Webhook registration endpoints that allow users to specify a callback URL
- PDF generation services that render user-provided URLs
- API integrations that accept endpoint URLs as configuration
- Import/export features that fetch content from URLs
An attacker provides a URL pointing to: http://169.254.169.254/latest/meta-data/ (AWS EC2 instance metadata) and the vulnerable server fetches and returns cloud credentials, instance roles, and configuration data.
What Attackers Can Reach via SSRF
Cloud metadata services
AWS, GCP, and Azure all expose metadata APIs at well-known local addresses (169.254.169.254 for AWS/Azure, 169.254.169.254 for GCP) that return IAM credentials, service account tokens, and configuration. These are accessible from any EC2/GCE/VM instance but not from the internet. SSRF bridges this gap.
Internal services
Applications behind firewalls — internal APIs, admin dashboards, message queues, databases with HTTP interfaces — are reachable from the application server but not from the internet. SSRF allows attackers to scan and interact with these services.
Cloud service APIs
AWS S3, internal load balancer endpoints, database management interfaces, Kubernetes API servers — accessible from within the VPC but not externally.
Prevention
Allowlist outbound destinations
The application should only make requests to a pre-defined list of approved destinations. Any URL not on the allowlist is rejected. This is the most effective defense.
Block internal IP ranges
Before making an outbound request, resolve the hostname and verify that the resulting IP is not in a private range (10.x, 172.16-31.x, 192.168.x, 127.x, 169.254.x, ::1). This prevents direct IP attacks and metadata service access.
Disable unnecessary URL schemes
Restrict outbound requests to https:// only. Block file://, gopher://, ftp://, and other schemes that can be used to access non-HTTP resources.
Network segmentation
Application servers should not have network access to sensitive internal services they do not need. Firewall rules limiting outbound connections reduce the blast radius of SSRF vulnerabilities.
| Target | What attacker gets | Severity |
|---|---|---|
| AWS EC2 metadata (169.254.169.254) | IAM credentials, role tokens | Critical |
| Internal admin APIs | Admin access to internal services | High |
| Internal network scanning | Network topology, open ports | Medium |
| Cloud storage (S3 via internal endpoint) | Data access without public endpoint | High |
| Kubernetes API server | Cluster control plane access | Critical |
SSRF and Autonomous Code Governance
Hydra detects SSRF by tracing user-controlled URL parameters to HTTP client calls — identifying code paths where attacker-supplied URLs reach fetch(), axios, requests.get(), HttpClient, or equivalent libraries without destination validation. Fixes add allowlist validation, internal IP blocking, and scheme restrictions appropriate to the framework and HTTP client in use. SSRF detection is a priority in cloud-native codebases where the blast radius of exploitation includes cloud credentials.
Frequently Asked Questions
How did SSRF become so important in cloud environments?
On-premises servers had limited internal networks to probe. Cloud VMs are surrounded by rich metadata services, service endpoints, and internal APIs — all accessible from the instance but not from the internet. SSRF turned the cloud metadata service into a trivially exploitable credential theft vector, making SSRF much more dangerous in cloud environments than in traditional hosting.
What is blind SSRF?
Blind SSRF occurs when the server makes the attacker-specified request but does not return the response to the attacker. The attacker can still use it for: network scanning (inferring open ports from response times), callback detection (using a controlled server to receive pings), and in some cases metadata service access (if error messages leak partial data).
Does URL validation in the frontend prevent SSRF?
No. SSRF is a server-side vulnerability. Frontend validation is bypassed trivially by sending the request directly to the API. Validation must happen server-side, after receiving the URL and before making the outbound request.
Stop flagging. Start fixing.
Hyrax reviews your pull requests, remediates issues autonomously, and closes the ticket.
Join the waitlist