Remi Huigen
Summary
It is currently difficult to reliably verify SavvyCal webhook signatures when using certain frameworks. Since the HMAC signature is generated from the
exact raw request payload
, if only the parsed JSON is available, the signature cannot be reproduced. This makes proper verification impossible in those environments.
---
### Problem
* Signature verification requires the
raw string
of the request body.
* Many frameworks parse the JSON body before user code can access it.
* Once parsed, the original raw string (with its exact whitespace, key ordering, and encoding) is lost.
* Attempting to
JSON.stringify
the parsed body is unreliable and does not consistently match the string SavvyCal used.
* As a result, webhook authenticity cannot be guaranteed in these setups.
---
### Why This Matters
* Security: Without reliable verification, webhook endpoints are vulnerable to spoofed requests.
* Developer Experience: Many developers integrating with SavvyCal don’t have low-level access to the raw request body. This creates friction and prevents secure usage.
---
### Suggested Solutions
#### 1.
Static Secret Verification (Preferred)
Provide an option for webhooks to include a static, pre-shared secret header (e.g.,
x-savvycal-secret
) instead of an HMAC over the body.
* This is simpler to implement in environments without raw-body access.
* Security is still strong, provided HTTPS is used and the secret is sufficiently random.
* Many webhook providers offer this as a fallback option for exactly this reason (e.g., Slack’s
signing secret
vs GitHub’s
secret
).
#### 2.
Dual Signature Headers
Include both:
* The existing
x-savvycal-signature
(HMAC of raw body).
* An optional
x-savvycal-secret
(static).
This would keep backward compatibility while giving developers flexibility.
#### 3.
Optional Canonical JSON Serialization
If sticking with HMAC verification only, provide a guarantee that the body is always serialized using a canonical JSON format (no whitespace differences, predictable key ordering, UTF-8 encoding).
* This would allow developers to
JSON.stringify
the parsed object and reliably match your HMAC.
* While less flexible, it makes signature verification feasible without needing raw-body access.
---
### Benefits
* Broader compatibility with modern frameworks and headless CMS platforms.
* Easier onboarding for developers integrating webhooks.
* Improved security posture, since more teams would be able to verify webhooks correctly instead of skipping verification.