Look for any place the server makes an HTTP request using a URL, host or path that came from a user. That includes webhooks, link previews, image fetchers and importers. Then check whether the destination is limited to an allow list, redirects are off, and the connection cannot reach internal addresses or cloud metadata.
The two cases
The OWASP SSRF Prevention Cheat Sheet separates two situations. In the first, the application talks to known, trusted destinations, and the answer is an allow list plus network restrictions such as firewalls and segmentation. In the second, the application must reach arbitrary external destinations, for example webhooks. An allow list is impractical there, so the cheat sheet describes a block list of internal and reserved ranges, along with a proof of legitimacy token exchanged with the target.
Knowing which case you are in changes the review. Case one should have a short, explicit list. Case two needs more careful network controls.
What to check in the diff
| Item | Reviewer question |
|---|---|
| Destination | Is the host matched against an explicit allow list? |
| URL parsing | Does the code accept full URLs from users? Parsers disagree on edge cases |
| Redirects | Is redirect following disabled in the HTTP client? |
| DNS | Is the resolved IP checked, not just the name? |
| Metadata | Can the request reach 169.254.169.254? |
| Retries | Do fallback connections follow the same rules? |
Why names are not enough
The cheat sheet warns that a domain on an allow list can still resolve to an internal address after validation, which is DNS rebinding. Its recommended approach is to resolve the name, check every A and AAAA result against permitted networks, and connect to the validated IP while keeping the original hostname for Host, SNI and certificate checks.
Redirects are the same trap. A validated URL can redirect to an internal target unless following redirects is turned off.
Pitfalls with deny lists and regex
Deny lists are described as bypass prone and a last resort. At a minimum they must cover localhost, private ranges, link local addresses, IPv6 unique local addresses, multicast and the metadata hosts. Blocking one hostname or one IP notation is easy to evade. Regex suits simple formats but is error prone for URLs, so prefer library functions and avoid accepting whole URLs from users where you can build the request from a matched host and fixed scheme, port and path.
Cloud metadata
Cloud metadata services at 169.254.169.254 are a common SSRF target for stealing credentials. The cheat sheet suggests moving to IMDSv2 on AWS and disabling IMDSv1, and calls this defense in depth rather than a complete fix. In review, ask which role the service runs under. An SSRF bug under a narrow role costs less.
Try it yourself
Run the API scan in the demo and note which findings concern input that influences outbound calls.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's dependency and SBOM scanning covers the HTTP client libraries your code uses. The free scan is at gold.safeguard.sh/scan.
Quick check
Is a domain allow list enough?
No. A name can resolve to an internal IP after validation, so check the resolved addresses at connection time.
Why disable redirects?
A validated URL can redirect to an internal target if the client follows redirects.
Sources
Last reviewed: 19 October 2026.
