Is your feature request related to a problem?
Currently, the webhooks allow you to specify a custom header to serve as a security mechanism. The problem is, this value is static and, if intercepted or leaked, is rendered null. If a malicious payload is sent using an intercepted header, there's also no way to validate whether the request came from Plunk or not.
Describe the solution you'd like
I would like the webhooks to be signed and to provide their signature in a header, making this security mechanism more robust against possible attacks.
Here are some examples:
The 2 above use a simple HMAC-SHA256 signature with a shared secret that is displayed to the user on the webhook administration page in each respective platform.
More complicated ways also exist, for example Kinde does this with JWKS and sending the payload as a JWT instead. This, in my opinion, is unnecessarily complicated, but I'm not a security expert.
Alternatives or workarounds
The best I could come up with is to encrypt (AES-GCM) a pre-defined secret consumer-side, then provide this ciphertext to Plunk. This, however, does nothing to protect against the header value being intercepted and reused.
Additional context
N/A
Is your feature request related to a problem?
Currently, the webhooks allow you to specify a custom header to serve as a security mechanism. The problem is, this value is static and, if intercepted or leaked, is rendered null. If a malicious payload is sent using an intercepted header, there's also no way to validate whether the request came from Plunk or not.
Describe the solution you'd like
I would like the webhooks to be signed and to provide their signature in a header, making this security mechanism more robust against possible attacks.
Here are some examples:
The 2 above use a simple HMAC-SHA256 signature with a shared secret that is displayed to the user on the webhook administration page in each respective platform.
More complicated ways also exist, for example Kinde does this with JWKS and sending the payload as a JWT instead. This, in my opinion, is unnecessarily complicated, but I'm not a security expert.
Alternatives or workarounds
The best I could come up with is to encrypt (AES-GCM) a pre-defined secret consumer-side, then provide this ciphertext to Plunk. This, however, does nothing to protect against the header value being intercepted and reused.
Additional context
N/A