Server-side Request Forgery (SSRF Attack)
A Guide to Server-side Request Forgery (SSRF Attack)
An SSRF attack exploits a server-side request forgery flaw, which can occur when an API fetches a remote resource using a URL supplied by the client without validating it. This allows an attacker to coerce the server into making requests to unintended destinations, even when a firewall or VPN sits in front of it.
SSRF has become more common as development patterns increasingly involve server-side URL fetching. Webhooks, URL-based file imports, link previews, and custom single sign-on integrations all ask the server to reach out to a client-supplied address. Each of those features is a potential SSRF entry point if the destination isn’t validated.
Cloud environments raise the stakes considerably. Internal metadata services are typically reachable over plain HTTP from inside the network, and an SSRF flaw exposes the credentials those services hold.
Key Takeaways
- Server-side request forgery (SSRF) occurs when an API fetches a remote resource using a URL supplied by the client without validating it, allowing attackers to force the server into making requests to unintended destinations
- SSRF is increasingly common because modern development patterns, such as webhooks, URL-based file fetching, URL previews, and custom SSO, all involve server-side fetching of client-provided URLs
- Cloud environments make SSRF especially dangerous, as internal metadata services are reachable over HTTP and can expose sensitive credentials if accessed via an SSRF attack
- Blind SSRF, where no response is returned to the attacker, is difficult to detect but still exploitable. Attackers can infer open ports and internal service availability through response timing differences
- Prevention relies on isolating resource-fetching mechanisms, enforcing allowlists of permitted origins, URL schemes, and ports, disabling HTTP redirects, and using well-tested URL parsers to avoid parsing inconsistencies
Why is it Dangerous
SSRF lets an attacker turn the API server itself into a proxy for reaching internal infrastructure. That access can allow:
- Access to internal services not meant to be reachable from outside the network
- Theft of cloud credentials exposed through internal metadata endpoints
- Bypass of network-level protections like firewalls and VPNs, since the request originates from a trusted server
- Blind SSRF, where no response is returned but port and service availability is still inferred from timing differences
Typical Manifestations
Organizations are at risk of SSRF when APIs:
- Fetch a URL supplied directly by the client, such as for a webhook or file import, without validating the destination
- Follow HTTP redirects automatically, letting an initially safe URL redirect to an internal address
- Lack any allowlist restricting which origins, schemes, or ports the server may reach
- Use inconsistent or poorly tested URL parsers, creating gaps between validation logic and actual request behavior
At a high level, the failure occurs when the server treats a client-supplied destination as trustworthy.
SSRF Containment Measures
Resource fetching needs to be isolated and constrained, not left open by default.
- Isolate the resource-fetching mechanism on its own network segment, since it typically needs to reach remote resources, not internal ones
- Enforce an allowlist of permitted origins, URL schemes and ports, and accepted media types
- Disable automatic HTTP redirects
- Use well-tested URL parsers to avoid inconsistencies that attackers can exploit
- Validate and sanitize all client-supplied input data
- Avoid sending raw responses from the fetched resource back to the client
A server that trusts any URL a client gives it will always be vulnerable to abuse.
