Server-Side Request Forgery lets an attacker make a server perform requests on their behalf, often reaching internal systems that were never meant to be internet-accessible — cloud metadata endpoints, internal admin panels, or databases behind a firewall.
Where SSRF hides
Any feature where the server fetches a URL based on user input is a candidate: URL preview generators, webhook configuration, image/file import from a URL, PDF rendering that fetches external resources. It's often not the obvious "fetch this URL" feature that's exploited — it's a less obvious one, like an avatar-from-URL upload field.
Why it's dangerous specifically for cloud environments
Cloud providers expose metadata endpoints (like 169.254.169.254 on AWS) that return instance credentials to anything running on that instance — including, if SSRF is exploitable, an attacker's crafted request routed through your server. This is one of the most severe real-world SSRF outcomes, often leading directly to cloud account compromise.
Validate destinations, not just format
Checking that user input "looks like a valid URL" doesn't prevent SSRF — http://169.254.169.254/ is a perfectly valid URL. Validation needs to check the resolved destination against a denylist of private/internal IP ranges (RFC 1918 ranges, link-local addresses, loopback) before the request is made.
Watch for redirect and DNS rebinding bypasses
A URL that passes initial validation (public IP) can redirect to an internal address, or use DNS rebinding (resolving to a public IP at validation time, then a private IP at request time). Validate the destination at request time, and consider disabling automatic redirect-following for any server-side fetch of user-supplied URLs.
Prefer an allowlist over a denylist where feasible
If the feature only ever needs to fetch from a known, limited set of external domains, allowlisting those explicitly is far more robust than trying to enumerate every private range and bypass technique to block.
Network-level defense in depth
Even with application-level validation, restrict outbound network access from application servers to only what's genuinely needed, so a missed SSRF path still can't reach sensitive internal services it was never authorized to reach.