Webhook Authentication
Webhook authentication is how a receiver proves that an incoming webhook came from the sender it claims to come from. In practice that means verifying a cryptographic signature on every request before acting on it, because a webhook endpoint is a public URL that accepts POSTs from anyone who finds it.
That failure mode is worse than it sounds. A forged "payment succeeded" event can trigger order fulfillment; a forged "user verified" event can grant access. Authentication is what keeps the webhook service sending the event and the application acting on it in agreement about who sent what.
Authentication methods that don't fit webhooks
Several familiar authentication methods are poor fits for webhooks, and it's worth understanding why.
Basic Authentication sends static credentials with every request, so a single leaked delivery log exposes them, and it says nothing about whether the request body was modified in transit. An API key in the URL is worse: URLs are recorded in server logs, proxy logs, and analytics tools, so the key leaks constantly by design. Cookie-based authentication assumes a browser session and doesn't fit server-to-server calls at all. And mTLS, while cryptographically sound, imposes certificate management on every receiver, which is unrealistic when your receivers are thousands of customers with varied infrastructure.
What to use instead
The recommended best practice for webhook authentication is signing. The sender computes an HMAC signature over each payload using a per-endpoint secret, and the receiver verifies the webhook signature before trusting the request. This proves both origin and integrity in a single check, and including a signed timestamp defeats replay attacks, where a captured legitimate request is re-sent later.
The Standard Webhooks specification writes that down concretely: an HMAC-SHA256 computed over the message ID, the timestamp, and the raw body, sent in a webhook-signature header alongside webhook-id and webhook-timestamp. Receivers recompute the HMAC with their secret, compare it in constant time, and reject any request whose timestamp falls outside a tolerance window, commonly five minutes. Verify against the exact bytes that arrived, since a middleware that re-serializes JSON changes the body and breaks the comparison.
Signatures should be layered with transport and operational controls: deliver exclusively over HTTPS so payloads and headers can't be read in transit, optionally validate the sender's published IP addresses as a defense-in-depth measure, and rate limit and monitor your endpoint so abuse is visible. None of these substitutes for signature verification, but together they close off the remaining angles.
Authentication on both sides
Webhook authentication usually refers to receivers verifying senders, but the reverse direction matters too. Senders should protect themselves from malicious endpoint registrations, which is the domain of SSRF prevention, and receivers that expose webhook URLs should keep them unguessable so authentication is the second line of defense rather than the only one.
For more on webhook authentication, check out our documentation on additional webhook authentication methods.
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