SSRF defence for webhooks: allowlist or denylist?

If your server only calls known systems, use an allowlist. If customers supply webhook URLs, an allowlist is rarely practical, so you need layered controls: block internal and metadata addresses, check the resolved IP at connection time, disable redirects and restrict the network. OWASP says deny-lists are bypass prone and should be a last resort.

Two situations, two designs

The OWASP SSRF cheat sheet splits the problem in two.

Case 1: destinations are known. The app calls identified internal or partner systems. Match the host against an exact allowlist, and build the request yourself. Fix scheme, port and path in code instead of copying them from input. Avoid accepting full URLs from users where you can.

Case 2: destinations are arbitrary. Webhooks and URL previews are typical. You cannot list every customer's endpoint, so the guidance shifts to blocking dangerous ranges and proving the destination is legitimate.

What a denylist must cover

If you are in Case 2, OWASP's minimum list includes:

• Loopback addresses, IPv4 and IPv6.
• Private ranges under RFC1918, plus IPv6 unique local and link local ranges.
• Multicast ranges.
• Cloud metadata addresses, including 169.254.169.254, metadata.google.internal and metadata.amazonaws.com.

The cheat sheet warns that application level filtering is hard. Addresses can be written in many encodings and internal names must be tracked centrally.

Controls that matter more than the list

1. Resolve, check, then connect to that IP. Checking DNS separately from connecting leaves a gap that DNS rebinding can use. Our rebinding post covers this.
2. Disable automatic redirects. A permitted URL can otherwise redirect to a forbidden target.
3. Limit schemes to HTTP and HTTPS.
4. Network controls. Use firewalls to give the service only the routes it needs, and segregate networks so illegitimate calls fail outside the application.
5. Cloud metadata hardening. OWASP calls IMDSv2 a defence in depth measure for AWS. Migrate and disable IMDSv1.

Proof of legitimacy for webhooks

For Case 2, OWASP describes a handshake. Before delivering events, your service sends a random token to the endpoint and expects the endpoint to return it through a constrained parameter. This shows the owner of the destination agreed to receive traffic. The cheat sheet suggests POST only, HTTP or HTTPS only, and verifying the target resolves only to public addresses.

Design checklist for a webhook sender

1. Run deliveries from an isolated worker with no access to internal services.
2. Validate and pin the resolved IP per connection.
3. Turn off redirect following.
4. Put timeouts and size caps on responses.
5. Do not return response bodies to users, since that turns blind SSRF into data exfiltration.
6. Log blocked attempts and alert on spikes.

If you only remember one thing, remember this: the list is a safety net, and the connection time check plus network limits do the real work.

Quick check

Sources

• OWASP Server Side Request Forgery Prevention Cheat Sheet

Last reviewed: 19 October 2026.