I have two kind of related questions, one is specific two webhooks security in general and the other about how Zapier triggers webhooks.
1. I’ve read a lot about webhooks recently. Every piece of information I read points out that, for security reasons, it’s best to use shared secrets and sign the payload (usually with HMAC) when sending a webhook request. I don’t quite understand this hassle.
Imagine I have a server side app. I want my app to receive a webhook from a different app (in other words, I want to subsribe to an event in a different app). So I create an URL in my app to accept the webhook. My app also has its own HTTP API that anyone authorized can call. Now the question. Why the webhook URL should have a different security appoach than any other API my app has? If the general API endpoints has authentication mechanism (let’s say with simple API key), why can’t the webhook URL use the same approach?
Well, I understand it can actually. What I don’t understand is that why, when it comes to webhooks, almost everyone says about using signature and preventing reply attacks and almost no one says the same when it comes to regular API calls? What is the crucial difference here? Let’s say we talk about HTTPS in both cases (obviously).
Just to clarify what I’m talking about, here is the doc from Zapier with best practices how to implement webhooks security: https://resthooks.org/docs/security/
2. Zaper has Webhooks app that can trigger outgoing webhooks. In the light of the above said, why it doesn’t seem to support signing the webhook payload? It’s especially strange, if we consider the suggestions in the doc from Zapier menioned above.
Could someone explain to me what I’m missing here?
Best answer by ZaneView original