Verifying webhooks
Why you should verify webhhoks
Because of the way webhooks work, attackers can impersonate services by simply sending a fake webhook to an endpoint. Think about it: it's just an HTTP POST from an unknown source. This is a potential security hole for many applications, or at the very least, a source of problems.
In order to prevent it every webhook and its metadata are signed with a unique key (the Signing Secret) for each endpoint. This signature can then be used to verify the webhook indeed comes from the Kript, and only process it if it is.
Another potential security hole is what's called replay attacks. A replay attack is when an attacker intercepts a valid payload (including the signature), and re-transmits it to your endpoint. This payload will pass signature validation, and will therefore be acted upon.
To mitigate this attack a timestamp is included for when the webhook attempt occurred. The Svix libraries automatically reject webhooks with a timestamp that are more than five minutes away (past or future) from the current time. This requires your server's clock to be synchronised and accurate, and it's recommended that you use NTP to achieve this.
Svix
Kript uses Svix to provide efficient webhook services, so you would come across Svix in several sections on using our webhook events.
How to verify
We have discussed why you need to verify webhooks events, now let's see how it's done. Svix already provides a great explanation on how how to verify these events using the signing secret for each webhook endpoint. Can't find the signing secret? Check out this page
docs.svix.comUpdated over 2 years ago