What SSRF is
SSRF stands for Server-Side Request Forgery. In plain terms: a flaw where the application's own server is tricked into making an HTTP request to an address the attacker chooses, instead of the address the system expected.
This usually shows up in very common, seemingly harmless features: importing an image from a URL, generating a PDF from a link, validating a webhook, fetching a preview from a shared link. Anywhere the system takes a URL from the user and makes a request based on it is a candidate for SSRF.
Why this is even worse in the cloud
Every modern cloud provider (AWS, GCP, Azure) exposes an internal metadata address, something like 169.254.169.254, only reachable from inside the machine's own network. That address returns information about the instance, including, in poorly configured setups, temporary credentials for the cloud account.
If the application server will make a request to any URL a user provides, and doesn't block that internal address, an attacker can make the server itself ask for that credential, and use the response to gain access to cloud resources well beyond the application itself.
The case
On an enterprise platform, in a public bug bounty program, a feature that accepted a user-supplied URL (part of an external content import feature) didn't validate whether that URL pointed to an internal address on the cloud network. This allowed access to the instance's metadata service, exposing internal information that should never be reachable from a user-facing feature.
The flaw was reported, fixed, and classified as critical, not for the direct damage during testing, but for its potential to escalate into broader access within the company's cloud environment.
How to prevent it
- Never trust a user-supplied URL directly for a server-side request without validation.
- Block outbound requests to internal IP ranges and cloud metadata addresses by default.
- Use an allowlist of expected domains instead of trying to block each dangerous domain individually.
- Restrict the cloud instance's own permissions to the minimum needed, so that even if metadata leaks, the damage stays limited.
This is exactly the kind of flaw automated scanners tend to miss, because the feature itself looks completely normal. It was found through manual testing, with the same methodology used to hunt vulnerabilities in bug bounty programs.
Does your application have any feature that accepts a URL from the user?
Request a Web Application Pentest