[tasn]

We already protect against reply attacks (we have a signed timestamp as part of the webhook), and I'm not sure what you mean by challenge-response checks. Do you mean things to protect against SSRF? If so, yeah, we also sign the webhooks in order to make sure they come from the right source.

Thanks for the link, will read it tomorrow!

[mlader]

A challenge response check will help ensure that the webhook consumer is actually using the webhook signature, and improve the likelihood that you are sending data to the right target. I saw a number of times that systems weren't verifying the data we were sending them came from us even though we had gone to all of this effort to help them :facepalm:.

Basically you periodically send a GET request to the target API with a token, and have them respond with the token encrypted with the same secret they'd use to decrpyt your webhook signature.

You could also consider sending dummy ping messages that may or may not have a valid signature (of course make sure this behavior is documented) that you would expect the target API to return a 4xx error if the signature is incorrect.

These extra steps are definitely not table stakes for a webhooks system, but could be enough to make sure the webhook event providers are being the best possible stewards of their user's data that they can =D. A lot of this complexity can also be wrapped by a client library you provide, which is a big win for everyone on its own.

Twitter's webhook API has an example of CRC btw! https://developer.twitter.com/en/docs/twitter-api/enterprise....

[tasn]

Ah I get what you mean now! Interesting way to ensure they are actually doing the right thing! I think the ping with the bad signature to check they are actually verifying the webhook is much lighter weight, and almost solves the same problem. The one with the signed response is also interesting, but a bit harder to get people to actually implement.