blursec.webhooks
Verify HMAC-SHA256-signed deliveries Blursec posts to your endpoint.
A credential or session can come back clean at login and only show up in a
stealer-log batch hours or days later. Webhooks are how Blursec tells you about
those after-the-fact compromises (e.g. session.compromised,
credential.leaked) so you can revoke proactively instead of waiting for the
next check.
Verification is local — it never round-trips to the Blursec API, so it
works in any runtime and adds no latency to your handler.
verify(options) → Promise<boolean>
Returns true only when both the signature is valid and the delivery
falls inside the replay window. Returns false for any malformed or stale
delivery — it never throws on a bad delivery, so a misbehaving sender can’t
crash your handler. It throws BlursecValidationError only when secret is
empty (caller misconfiguration).
Pass the raw request body. The signature is computed over the exact bytes Blursec sent. Any JSON re-serialization or whitespace normalization by your framework will invalidate it — use a raw-body parser on the webhook route.
VerifyWebhookOptions
Delivery headers
Blursec sets these headers on every delivery. They’re also exported as a typed bag (BLURSEC_WEBHOOK_HEADERS) and surfaced on blursec.webhooks.headerNames
so framework adapters wire them up consistently:
The default replay-protection window is 5 minutes
(
DEFAULT_WEBHOOK_TOLERANCE_MS, also on blursec.webhooks.defaultToleranceMs).
Override it per call with toleranceMs.
Standalone verification (no client)
verify is a thin wrapper over the exported verifyWebhookSignature helper.
Use the helper directly in an edge handler that doesn’t otherwise need a
BlursecClient:
signWebhookPayload(...) produces a valid signature for a given
secret + payload + timestamp so you can exercise your handler end-to-end.
