Webhook Security
Verify webhook authenticity and implement security best practices
Webhook security is critical to ensure that requests to your endpoint are actually coming from Sent and haven't been tampered with. This page covers how to verify webhook authenticity and implement security best practices.
Why Webhook Security Matters
Without proper verification, attackers could:
- Send fake webhook requests to trigger unwanted actions
- Modify payload data to manipulate your application
- Overload your webhook endpoint with requests
How Sent Signs Webhooks
Sent signs every webhook request using HMAC-SHA256 encryption with your account's secret key. This creates a unique signature for each request that proves:
- The request came from Sent
- The payload hasn't been modified
Finding Your Secret Key
Each webhook endpoint has a unique secret that's used to sign all requests to that endpoint.
To access your webhook secret, you can click on your desired webhook endpoint in your Sent Dashboard and click on the Eye Icon button to view the secret, or you can click on the Copy button to copy the secret to your clipboard.
Keep Your Secret Secure
Keep your webhook secret secure and never expose it publicly. If you believe your secret has been compromised, regenerate it immediately from your dashboard settings.
Signature Verification
How Signatures Work
Each webhook request includes several headers for verification:
| Header | Description | Example |
|---|---|---|
x-webhook-signature | HMAC-SHA256 signature | v1,abc123... (base64) |
x-webhook-id | Unique webhook endpoint ID | 550e8400-e29b-41d4-a716-446655440000 |
x-webhook-timestamp | Unix timestamp (seconds) | 1705334531 |
x-webhook-event-type | Event type | messages or templates |
The signature format is:
x-webhook-signature: v1,{base64_encoded_signature}The signature is computed as follows:
- Strip the
whsec_prefix from your signing secret - Base64-decode the remaining secret to get raw key bytes
- Concatenate:
{webhookId}.{timestamp}.{payload}(dot-separated) - Compute HMAC-SHA256 using the raw key bytes
- Base64-encode the result
- Prefix with
v1,
Step-by-Step Verification
Extract headers - Get x-webhook-signature, x-webhook-id, and x-webhook-timestamp
Prepare your secret - Strip the whsec_ prefix and Base64-decode to get raw bytes
Build signed content - Concatenate: {webhookId}.{timestamp}.{rawBody}
Compute HMAC-SHA256 using the decoded secret key bytes
Compare signatures using a timing-safe comparison function
Only process the webhook if signatures match
Replay Attack Prevention
You should also verify that the timestamp is recent (within 5 minutes) to prevent replay attacks.
Security Best Practices
Always Validate Signatures
Never trust a webhook request without signature verification:
// ❌ BAD - No verification
app.post('/webhook', (req, res) => {
processWebhook(req.body); // Dangerous!
res.status(200).send('OK');
});
// ✅ GOOD - Verified first
app.post('/webhook', (req, res) => {
if (!verifySignature(req)) {
return res.status(401).send('Unauthorized');
}
processWebhook(req.body);
res.status(200).send('OK');
});Use Timing-Safe Comparisons
Standard string comparison can leak timing information. Use dedicated functions:
- Node.js:
crypto.timingSafeEqual() - Python:
hmac.compare_digest() - Go:
subtle.ConstantTimeCompare() - Other languages: Look for "constant-time" or "timing-safe" comparison functions
Why Timing-Safe Comparisons?
Regular string comparison (==) can exit early when it finds a mismatch, potentially leaking information about the correct signature through timing analysis. Timing-safe functions always compare the entire string, preventing this attack vector.
Require HTTPS
Always use HTTPS endpoints for webhooks:
{
"url": "https://your-app.com/webhook" // ✅ Secure
}{
"url": "http://your-app.com/webhook" // ❌ Insecure
}HTTPS Required
Sent will only deliver webhooks to HTTPS endpoints. HTTP endpoints will be rejected during webhook configuration.