Server-Side Request Forgery (SSRF)
Also known as: SSRF
Server-Side Request Forgery (SSRF) occurs when an application fetches a remote resource using a URL that an attacker can influence, without adequately validating the destination. Because the request originates from the server, it can reach internal systems, cloud metadata services, and other resources that are not directly exposed to the internet - bypassing network-level access controls.
How it works
- 1The application accepts a URL or hostname from user input (a webhook, image fetcher, PDF renderer, or link preview).
- 2Validation is missing or bypassable - for example, only the first DNS resolution is checked, allowing DNS rebinding.
- 3The attacker points the request at an internal address such as the cloud metadata endpoint (169.254.169.254) or an internal admin service.
- 4The server fetches the target and returns or acts on the response, leaking secrets or reaching otherwise-unreachable systems.
Example
POST /api/webhooks/test HTTP/2
Host: target.example
Content-Type: application/json
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }Impact
SSRF can expose cloud credentials, internal APIs, and configuration data, and is frequently the first link in a chain that escalates to full infrastructure compromise.
Remediation
- Validate and allowlist destination hosts; reject link-local, loopback, and private IP ranges after DNS resolution.
- Resolve the hostname once and connect to that pinned IP to prevent DNS rebinding.
- Require IMDSv2 (hop-limit 1) on cloud instances so metadata cannot be reached via SSRF.
- Route outbound fetches through an egress proxy with an explicit allowlist.
Detection & testing
Look for user-controlled URLs reaching internal ranges, unexpected requests to metadata endpoints, and outbound connections from services that normally never egress.
Impactr tests for Server-Side Request Forgery (SSRF) the way an attacker would - investigating, chaining it with related flaws, and proving impact with a reproducible exploit before it reaches your report.
Test my app for SSRFTools
Frequently asked questions
What is the difference between SSRF and CSRF?
SSRF abuses the server to make requests on the attacker's behalf, typically to reach internal systems. CSRF abuses an authenticated user's browser to perform actions on a site they are logged into. They target different trust boundaries.
Why is the cloud metadata endpoint a common SSRF target?
The metadata service (169.254.169.254 on AWS/GCP/Azure) returns instance credentials and configuration to anything that can reach it from the host. SSRF gives an attacker that reach, so it often yields IAM credentials.