Server-Side Request Forgery (SSRF)
detect, understand, remediate
SSRF allows attackers to make the server send requests to internal services, cloud metadata endpoints, or other restricted resources, potentially leading to data exfiltration or remote code execution.
No credit card required. Free plan available forever.
What is server-side request forgery (SSRF)?
Server-side request forgery (SSRF) is a vulnerability that allows an attacker to induce the server to make HTTP requests to an arbitrary destination of the attacker's choosing. Because the request originates from the server itself, it can reach internal services, private networks, and cloud infrastructure metadata endpoints that are not directly accessible from the internet.
SSRF has become significantly more dangerous with the adoption of cloud infrastructure. Cloud providers expose instance metadata services at well-known addresses (such as 169.254.169.254 on AWS) that return temporary credentials, API keys, and configuration data. A single SSRF vulnerability can give an attacker access to the cloud provider's IAM credentials, potentially compromising the entire cloud environment.
Beyond cloud metadata, SSRF can be used to port-scan internal networks, access internal admin panels, interact with internal APIs that lack authentication (because they trust requests from the internal network), read local files via the file:// protocol, and in some cases achieve remote code execution. SSRF was added to the OWASP Top 10 as a standalone category in 2021, reflecting its growing impact.
How it works
Application accepts URL input
The application has a feature that accepts a URL, such as a webhook callback, URL preview, PDF generator, file import, or image fetch endpoint.
Attacker supplies internal URL
Instead of a legitimate external URL, the attacker provides an internal address like http://169.254.169.254/latest/meta-data/ or http://127.0.0.1:8080/admin.
Server fetches the URL
The server makes the request using its own network identity and credentials. Internal firewalls and security groups allow the request because it originates from a trusted server.
Internal data returned
The response containing cloud credentials, internal API data, or configuration information is returned to the attacker, either directly in the response or via an out-of-band channel.
Common causes
URL parameters passed to HTTP clients
Application features that fetch remote resources based on user-supplied URLs without restricting the destination to external, public addresses.
PDF generators and preview services
PDF rendering engines and link preview services that fetch URLs to generate content, allowing attackers to target internal endpoints through document generation.
Webhook and callback URLs
Webhook registration endpoints that accept arbitrary callback URLs, allowing attackers to direct the server to make requests to internal services.
File import from URLs
Import features that fetch files from user-provided URLs (e.g. import CSV from URL, fetch image from URL) without validating the destination.
How to detect it
Automated detection
- SecPortal's authenticated scanner tests SSRF vectors against AWS, GCP, and Azure metadata endpoints, as well as common internal IP ranges
- SecPortal's code scanner identifies HTTP client calls that accept user-controlled URLs without validation or allow-listing
- DNS rebinding detection tests whether URL validation can be bypassed by resolving an external hostname to an internal IP address
Manual testing
- Supply http://127.0.0.1, http://localhost, and http://[::1] to URL input fields and observe whether the server makes the request
- Test cloud metadata URLs (http://169.254.169.254/latest/meta-data/) to check for credential exposure on cloud-hosted applications
- Use DNS rebinding tools and alternative IP representations (decimal, hex, octal) to bypass naive URL validation filters
How to fix it
Implement URL allow-listing
Maintain a strict allow-list of permitted domains and URL schemes. Only allow requests to known, trusted external destinations. Deny all URLs that do not match the allow-list.
Block private and reserved IP ranges
Resolve the destination hostname before making the request and reject any IP in private 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), and IPv6 equivalents.
Use dedicated service accounts with minimal permissions
Run URL-fetching services with dedicated credentials that have no access to internal resources or cloud metadata. On AWS, use IMDSv2 which requires a PUT request with a TTL header that browsers and simple HTTP clients cannot easily forge.
Disable unnecessary URL schemes
Restrict URL schemes to https:// only. Block file://, gopher://, dict://, ftp://, and other schemes that can be used to access local files or interact with internal services.
Validate DNS resolution before and after requests
Resolve the URL hostname and validate the IP before making the request. Re-validate after following any redirects, as attackers may use redirects to bypass initial validation.
Compliance impact
Related vulnerabilities
Detect SSRF automatically
SecPortal tests for SSRF to internal services, AWS/GCP/Azure metadata endpoints, and DNS rebinding. Start scanning for free.
No credit card required. Free plan available forever.