What is webhook security?
Webhook security is the set of practices that protect a webhook endpoint from forged, tampered, and replayed requests. A webhook endpoint is a public URL that accepts HTTP POSTs, so without verification, anyone who discovers the URL can send it fake events. Securing webhooks means proving each request came from the real provider, arrived unmodified, and isn't a stale copy of an earlier delivery.
Why webhook endpoints are exposed
A webhook is just an HTTP request from a provider to a URL you registered, and that URL has to be reachable from the internet for the provider to deliver to it. Nothing about the transport itself distinguishes a legitimate event from a request an attacker crafted, and URLs leak: they end up in logs, config files, browser history, and error trackers.
That exposure creates three distinct threats. Spoofing is an attacker sending fabricated events to your endpoint, such as a fake payment.succeeded that ships an order nobody paid for. Tampering is modifying a legitimate payload in transit. Replay is capturing a real, validly signed request and sending it again later, which is covered in depth in the replay attack entry.
The Standard Webhooks specification, which Svix co-created, exists largely to give providers and consumers one well-reviewed answer to all three, instead of every provider inventing its own scheme.
Signature verification
The core defense is the webhook signature. The provider computes an HMAC-SHA256 over the message ID, a timestamp, and the raw payload using a secret shared with the receiver, and sends the result in a header. The Standard Webhooks spec defines the header as webhook-signature, alongside webhook-id and webhook-timestamp; older provider-specific conventions include Stripe-Signature and GitHub's X-Hub-Signature-256.
The receiver recomputes the same HMAC with its copy of the secret and compares the two. A match proves both origin and integrity in one check: only someone holding the secret could have produced the signature, and any change to the payload invalidates it.
Two implementation details matter more than they look. Verify against the raw request body, exactly as it arrived, because re-serializing parsed JSON changes bytes and breaks the comparison. And compare signatures with a constant-time comparison function, since ordinary string equality can leak information through timing differences.
Replay protection
A valid signature proves who sent a message, not when. The signed content includes a timestamp so receivers can reject messages outside a short tolerance window of the current time, commonly five minutes. Because the timestamp is inside the signed content, an attacker can't freshen a captured request without invalidating its signature.
For the window where a replay would still land, the spec recommends idempotency: track recently seen webhook-id values and drop duplicates. The replay attack entry walks through the attack and both defenses in detail.
Securing the receiving side
Verification stops forged input, but the endpoint itself needs the same care as any production HTTP handler.
- HTTPS only. Signatures protect integrity, not confidentiality; payloads often carry customer data, so endpoints should refuse plain HTTP.
- Fail closed. Reject requests with missing or malformed signature headers rather than falling through to processing.
- Don't leak in error responses. Return a bare 4xx on verification failure; detailed errors help an attacker probe the scheme.
- Rotate secrets. Treat the signing secret like any credential. Well-behaved providers sign with both old and new secrets during a rotation window so receivers can switch without dropped verifications.
Securing the sending side
Providers have their own exposure: the URLs customers register are attacker-controlled input. A customer can point a webhook at 169.254.169.254 or an internal service and use your delivery infrastructure to probe your network, an attack class called SSRF (server-side request forgery). Senders should resolve and deliver from an isolated network segment or proxy, block private IP ranges, and re-check on redirects.
Senders also carry the other half of the practices above: generating strong per-endpoint secrets, supporting rotation, and publishing SDKs so receivers don't hand-roll verification. Most providers, Svix included, ship verification libraries, and using one is almost always better than implementing the checks yourself.
For a full treatment of both sides, see our webhook security best practices and the security course in Webhooks University.
Frequently asked questions
Are webhooks secure by default?
No. A webhook is a plain HTTP POST to a public URL, and nothing in the transport authenticates the sender. Security comes from what the provider and receiver add on top: HTTPS, signature verification, timestamp checks, and idempotency.
What is the most important webhook security measure?
Signature verification. An HMAC-SHA256 signature over the message ID, timestamp, and raw body proves the request came from the provider and was not modified in transit, which covers the two most damaging attacks in a single check.
Is checking the source IP address enough to secure a webhook?
No. IP allowlists are brittle because provider IPs change, and they prove nothing about payload integrity. They can be a supplementary layer, but signature verification is the primary control.
Do I still need webhook security if my endpoint URL is secret?
Yes. URLs are not credentials: they appear in logs, config files, and error trackers, and anyone who learns the URL can post to it. A secret URL slows an attacker down; a verified signature stops them.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis