Webhook Security: Signatures and Replay Defense

Every reputable webhook provider signs the payload. Stripe uses HMAC-SHA256 with a per-customer signing secret. GitHub uses HMAC-SHA1 (and HMAC-SHA256 in newer versions). Twilio uses HMAC-SHA1 over the URL plus form parameters. Verify the signature on every incoming webhook. Skipping verification means anyone who can guess your endpoint can fire fake webhooks.

// Pseudocode
const expected = hmac_sha256(secret, raw_body);
if (!timing_safe_equal(expected, request.headers["x-signature"])) {
  reject();
}

• Using string equality instead of constant-time comparison — leaks timing information about the expected signature
• Verifying the parsed JSON instead of the raw body — any whitespace difference breaks verification but parsing first means an attacker can sometimes craft a body that parses differently than it serialized
• Trusting the timestamp header without bounding it — replay attacks become trivial without a freshness check
• Using one signing secret across all webhook destinations, when each should be per-customer

Even with signature verification, an attacker who captures a webhook (via SSRF, log access, etc) can replay it. Defenses: include a timestamp in the signed payload and reject anything older than N minutes; track recently-seen idempotency IDs in a cache and reject duplicates.

If your service sends webhooks, sign them and document the verification flow for customers. Include enough metadata for customers to detect replay. Allow customers to rotate signing secrets without downtime.

See API security testing.