SSRF: The Cloud-Era Vulnerability That Bypasses Your Firewall

Server-Side Request Forgery earned its own spot on the OWASP Top 10 in the 2021 edition differently than every other category on the list at the time, it was added based directly on the security community's own survey input, not purely historical incident data, because practitioners were already seeing it become disproportionately dangerous as more infrastructure moved to the cloud. In the 2025 edition, SSRF (CWE-918) was folded into the broader Broken Access Control category (A01:2025) rather than standing alone, a reflection of how it's fundamentally an authorization failure at the request layer, not a shrinking of its severity. The mechanism itself hasn't changed: SSRF happens whenever an application fetches a remote resource without validating the user-supplied URL, letting an attacker coerce the server into making a request to a destination it was never meant to reach, even when a firewall or VPN sits in front of the application itself.

Why cloud infrastructure made this worse, not better

Every major cloud provider exposes an internal metadata service at a well-known, unauthenticated address (169.254.169.254 on AWS, Azure, and GCP alike) that hands back real, live credentials for whatever role the instance is running as, no login required, because it's designed to be reachable only from inside the instance itself. An SSRF vulnerability in an application running on that instance turns "fetch this URL the user gave us" into "fetch the cloud provider's own credential-issuing endpoint on the attacker's behalf", frequently escalating a single input-validation bug directly into full cloud account compromise, not just an internal network scan.

Where it shows up

• "Fetch this image/file from a URL" features, profile pictures, document imports, webhook-triggered fetches
• PDF or document generation that renders a user-supplied URL or embedded link server-side
• Webhook and integration features that call back to a URL the user configures
• Any "preview this link" or URL-unfurling feature, which by definition fetches attacker-influenced URLs server-side
• Internal API calls built from user input, where the "internal" destination was assumed safe by virtue of not being public-facing

Why a firewall doesn't stop it

SSRF specifically defeats network-perimeter controls, because the malicious request doesn't come from the attacker's machine, it comes from your own server, which the firewall already trusts. Blocklisting 169.254.169.254 or localhost directly is also not a real fix on its own; attackers routinely bypass naive blocklists with alternate IP representations, DNS rebinding, or open redirects the vulnerable server follows.

What real testing confirms

• Every feature that fetches a remote resource based on user input, tested against internal and cloud-metadata targets specifically, not just external URLs
• Whether allowlist-based validation (not blocklist) is actually enforced on the scheme, port, and destination
• Whether HTTP redirects are followed, which is how many blocklist-based defenses get bypassed in practice
• Real impact confirmation, whether the vulnerability actually reaches cloud metadata or internal services, not just a theoretical finding

This is standard scope across our Web & API Security and Cloud Security engagements, SSRF sits exactly at the intersection of both, which is why it needs testing that covers the application layer and the cloud infrastructure it runs on together. See our companion piece on common cloud security misconfigurations for the broader infrastructure-level gaps SSRF often chains into.