The Hidden Security Flaw in Webhook Systems: SSRF via Delivery Workers

Webhook security is one of those areas where the industry has it completely backwards. We spend countless hours perfecting HMAC signatures, validating payloads, and securing our webhook ingestion endpoints, but we're ignoring the real threat vector that's staring us right in the face.

The Wrong Side of the Security Conversation

Let me be blunt: if you're only securing your webhook ingestion and not your delivery worker, you're doing it wrong. The security conversation around webhooks is almost universally focused on inbound verification, while the outbound side remains a gaping security hole.

HMAC verification is great for what it does—it proves that a payload came from who it claims to be. But here's the critical insight: HMAC doesn't protect your delivery worker at all. That signature is completely irrelevant when your system is making outbound HTTP requests to tenant-provided URLs.

Think about the typical flow: A tenant registers https://totally-legit-domain.com/webhook as their endpoint. You validate the URL looks legitimate, maybe check it doesn't resolve to a private IP, and then move on. But this one-time validation is the root of the problem.

DNS Rebinding: The Actual Scary Part

Here's where it gets ugly, and this isn't theoretical—it's happening right now in production systems everywhere.

The attack works like this:

→ Tenant registers a domain they control → At registration time, it resolves to a perfectly normal public IP → Your validation passes → Later, the DNS record flips to 169.254.169.254 (the cloud metadata endpoint) → Your delivery worker happily POSTs to it, potentially leaking cloud credentials

Your worker just became a proxy into your own infrastructure. The tenant didn't hack anything. They just gave you a URL and waited.

🎯 This isn't theoretical. Cloud metadata endpoints are the crown jewels. One leaked IAM credential from that 169.254 address and it's game over for your entire cloud environment.

The Validation Problem

The fundamental issue is that most systems validate URLs at registration time, not at delivery time. This is a catastrophic mistake. DNS records change. That's literally what DNS rebinding exploits.

Every single outbound request from your delivery worker needs to:

→ Resolve the hostname fresh at delivery time → Check the resolved IP against a private range blocklist before opening the connection → Reject anything pointing to 10.x, 172.16-31.x, 192.168.x, 169.254.x, or localhost

Some HTTP libraries will follow redirects automatically too. A 302 hop to an internal IP is just as dangerous. You need to validate at every step of the chain, not just the initial resolution.

This Is an Architecture Problem

The frustrating part is that most webhook guides treat security as "add HMAC and you're done." That's security theater for the delivery path.

🔒 If you're building a webhook system, the delivery worker is the most dangerous component you own. It makes outbound HTTP requests to attacker-controlled URLs. Read that sentence again. You're essentially running an HTTP client that takes instructions from your tenants.

That deserves the same paranoia you'd give to user-uploaded code execution.

At a high level, the decisions that actually matter:

→ Pin DNS resolution to the moment of delivery and validate the IP → Disable HTTP redirects or re-validate after each hop → Run delivery workers in a network segment with no access to internal services or metadata endpoints → Treat every tenant URL as hostile, every time, forever

The Real Fix

Your inbound webhook security is probably fine. Your outbound delivery worker is probably a loaded footgun pointed at your cloud metadata endpoint.

The fix isn't complicated—validate DNS resolution at delivery time, block private IPs, isolate the worker network. But you have to actually do it, and most teams don't because every tutorial stops at HMAC.

What does your webhook delivery pipeline look like—are you validating resolved IPs on every outbound request, or just at registration time?

The security community needs to shift the conversation. We need to stop treating webhook delivery as an afterthought and start recognizing it for what it is: the most dangerous part of your webhook infrastructure.

Because right now, while you're busy perfecting your HMAC implementation, an attacker is registering a domain, waiting for DNS propagation, and planning their move to your cloud metadata endpoint. And your delivery worker will happily help them get there.