Use an allow-list whenever your server only needs to reach known destinations. If users can point it at any public address, as with customer webhooks, a deny-list of internal ranges is the fallback, and it has to be combined with disabled redirects and network level controls.
Why webhooks are the classic case
Server-Side Request Forgery, API7:2023, happens when an API fetches a remote resource from a user-supplied URL without validating it. OWASP notes the risk is growing because of webhooks, URL-based file fetching, custom SSO and link previews.
OWASP's webhook scenario is vivid. A security product's API sends a test request to a user's webhook URL and shows the response. An attacker points the URL at a cloud metadata service, and the returned credentials appear on screen.
Case 1: you know the destinations
The OWASP SSRF cheat sheet separates two cases. In the first, the application only needs to reach identified internal or partner systems. Here an allow-list works well:
- Validate IP addresses with a vetted library and compare against trusted addresses.
- Validate domain names for format and match against an allow-list.
- Do not accept full URLs. Build the request yourself from the matched host, with fixed scheme, port and path.
- Reject the input if two URL parsers disagree about it.
- At the network layer, segment so the app can only reach approved destinations.
Case 2: users supply any external address
Webhooks usually land here. An allow-list is impractical, so the cheat sheet falls back to a deny-list of internal and non-public ranges, with a warning: deny-lists are bypass-prone, so prefer allow-lists wherever you can.
When you must use one:
- Confirm the destination is public.
- Allow only HTTP and HTTPS.
- Build the request from validated data.
- Disable redirects.
- Consider proving legitimacy with a random token the receiver must send back.
The cheat sheet lists ranges to block at minimum: cloud metadata endpoints and 169.254.169.254, localhost, RFC 1918 private ranges, IPv6 unique local and link-local ranges, and multicast.
Decision guide
- Is the destination set small and known?: If yes: Allow-list, no free text URLs; If no: Go to next question
- Must users enter any URL?: If yes: Deny-list plus public-only check, no redirects, egress controls; If no: Reconsider the feature
- Do you show the response to the user?: If yes: Stop. Do not return raw remote responses; If no: Still log and limit size
OWASP's own prevention list also says to isolate the fetching component from internal networks and not to return raw remote responses to clients.
Cloud metadata
For AWS, the cheat sheet recommends moving to IMDSv2 and disabling IMDSv1, which mitigates some SSRF cases. Treat it as a second layer, not a replacement for validation. For redirect and DNS tricks, see the DNS rebinding post.
Quick check
Is a regex on the hostname enough?
No. Parsers disagree, and names can resolve to internal addresses. Validate the resolved address too.
Can I just block the metadata address?
Blocking it is a good minimum, but a deny-list alone is bypass-prone. Add egress controls and disable redirects.
Safeguard's dependency scanning can flag known SSRF advisories in the HTTP and URL parsing libraries you ship, and the free scan at gold.safeguard.sh/scan is a quick start.
Sources
Last reviewed: 19 October 2026.
