2 ms·
I can never understand why enforcing (sane and secure) TLS and adding a (shared) secret request header isn't the usual simple answer. As far as I know, TLS pre
by weddpros 6y ago
I can never understand why enforcing (sane and secure) TLS and adding a (shared) secret request header isn't the usual simple answer.
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...
- LunaSea 6y agoTLS with certificate pinning could probably even take care of the authentication issue.
- tasn 6y agoI'm the developer of Diahook (we do webhooks as a service), and I agree. It's just so annoying that we have to implement signing ourselves instead of just using client TLS certificates. Though the problem is that there are so many places in the stack that interact with your request before it hits user code (load balancer, web server, etc), that getting anything like this to work is wishful thinking...