Collection of best practices for providing and consuming webhooks

Re:Collection of best practices for providing and consuming ... by tasn on Friday August 19, 2022 @10:20AM (#32521289)

Migrating to a new service: you can just update the webhook URL. On the other hand, there are at least a couple of problems with allowing even one redirect: it opens a pandora's box of security implications, and it's a performance penalty that is paid both by the sender and the receiver on every webhook sent. Realistically, 3xx are most likely to be a mis-configurations (e.g. including a trailing slash where one shouldn't) so I think being noisy about it is a great idea.

Not saying that there aren't valid use-cases (e.g. maybe some sort of dynamic webhook receiving), I'm just saying that we made this choice given the above, and we would be willing to change it if it's ever a barrier for someone.

[ Parent | on HN ]

Re:Collection of best practices for providing and consuming ... by pyjug on Friday August 19, 2022 @10:38AM (#32521544)

>you can just update the webhook URL

Fair enough, but often consumers that use multiple vendors receive webhooks in the same service; think about going from /v1/webhooks -> /v2/webhooks, they'd have to change the URL for every vendor. Easier to redirect first then update the URLs later. I think it's a reasonable expectation that a HTTP client would honor redirects as long as the usage isn't malicious (like loops etc)

[ Parent | on HN ]