I wanted to implement Seatable webhooks in our business environment and I noticed that “x-seatable-signature” (which by the way has the wrong casing in the UI) is just a static hash of the secret key.
My question is why it was chosen to send this static hash instead of a dynamic hash? Isn’t this a potential security vulnerability since the signature basically is still a key? From my understanding, if an attacker was able to somehow capture a webhook call, they could easily forge new requests, as the signature is static and never changes. Wouldn’t it be therefore better to instead sign the whole body using the secret key in order to verify & validate the request? Alternatively, what would be the best way to verify and validate incoming webhooks?
The x-seatable-signature is a key now that prevent your web site from receiving a webhook from anyone. HTTPS should be used so that the signature can’t be easily be captured.
You suggestion of using a dynamic one is an improved solution, we will give it a check.
Hey @daniel.pan, thanks for your reply! Yes that makes sense, but for me it seems a bit pointless to sign the key if the signature never changes (and thus becoming a key itself)
Looking forward to see if you can somehow implement a payload signature, although I could imagine it would be difficult to change the webhook format, since Zapier and co depend on it (maybe an additional signature header could be passed along?)
