Building Webhooks into Your Application: Guidelines and Best Practices (2020)

As far as I know, TLS prevents all these security issues, except authentication of the webhook caller, hence the shared secret which your webhooks should check.

I've verified in the TLS specs that every issue I've seen raised by people is actually covered, yet people still think (and write) that TLS doesn't sign traffic (it does), or TLS doesn't prevent replay attacks (it does), etc.

Usually I give them pointers to the specs, and they say "it doesn't hurt to add even more security" but they're really rolling out their own encryption, which you shouldn't do.

I'd say enforce TLS and authenticate the webhook caller...

Lots of people have written about how to scale event-based systems or how to design distributed infrastructure for queue management. But what's often overlooked is the subtle-yet-important product decisions that go into designing webhooks for a great developer experience.

We don't actually offer webhooks-as-a-service at WorkOS, but we provide webhooks to developers and I've built this feature twice now, previously at Nylas and now at WorkOS. Hopefully this article helps the next person who builds them. :)

For anyone curious how we do it at WorkOS, here's our webhooks API reference: https://workos.com/docs/reference/webhooks/connection

This isn't the security guarantee that signing, etc. are but it's a substantial help in adding some Security In Depth.

1 - https://stripe.com/docs/ips

1 - https://aws.amazon.com/blogs/compute/using-api-destinations-...

Anyhow, I wish more people had better webhooks, it's such an important part of any API, so please read this blog post, understand the challenges, and provide a great webhooks experience!

[1] https://news.ycombinator.com/item?id=26399672

I've always been a huge fan of how Stripe handles their webhooks. They are pretty much doing everything listed in your article.