Skip to content
Calcrivo

Webhook Verification Calculator

Score webhook authenticity controls — signature algorithm, secret entropy, timestamp tolerance, replay cache and constant-time compare.

Inputs

bits
seconds

Weight 16

Weight 12

Weight 8

Weight 4

days
events/s

Verification Score

71/ 100

Verification Grade

C — Fair

Effective Forgery Resistance

256bits

Events Replayable Inside the Window

15,000

Timing Side Channel

Closed — comparison time does not depend on the signature

Highest-Value Fix

Cache delivered event IDs and reject duplicates

Step by step

  1. Values used

    Signature algorithm = HMAC-SHA256 — 256-bit tag; Shared secret entropy = 256 bits; Timestamp tolerance = 300 seconds; Replay cache keyed on event ID or signature = No; Constant-time signature comparison = Yes; TLS certificate verification on delivery = Yes; Unique secret per endpoint = No; Secret rotation interval = 180 days; Peak delivery rate = 50 events/s

  2. Webhook Verification

    Verification score = 30 for ≥128-bit forgery resistance + timestamp tolerance score (20 at ≤60 s down to 0 above 15 min) + 16 replay cache + 12 constant-time compare + rotation score (10 at ≤90 days) + 8 TLS verification + 4 per-endpoint secret = 100.

  3. Replay window

    replayable events = timestamp tolerance × peak delivery rate, when no replay cache is present.

  4. Verification Score

    = 71 / 100

  5. Verification Grade

    = C — Fair

  6. Effective Forgery Resistance

    = 256 bits

  7. Events Replayable Inside the Window

    = 15,000

  8. Timing Side Channel

    = Closed — comparison time does not depend on the signature

  9. Highest-Value Fix

    = Cache delivered event IDs and reject duplicates

How it works

Forgery resistance is the weaker of the algorithm and the secret — HMAC-SHA256 over a 32-bit secret is a 32-bit problem — so the two are combined before scoring. A signature alone is not enough: without a timestamp and a replay cache, a captured delivery can be resent, which is why those two terms carry 36 points between them. A webhook endpoint is an unauthenticated write path into your system, and the usual failures are comparing signatures with == and accepting any timestamp.

Formulas

Webhook Verification

Verification score = 30 for ≥128-bit forgery resistance + timestamp tolerance score (20 at ≤60 s down to 0 above 15 min) + 16 replay cache + 12 constant-time compare + rotation score (10 at ≤90 days) + 8 TLS verification + 4 per-endpoint secret = 100.

effective bits
min(algorithm tag strength, secret entropy)
timestamp tolerance
How stale a signed request may be

Replay window

replayable events = timestamp tolerance × peak delivery rate, when no replay cache is present.

peak delivery rate
Events per second at peak
replay cache
Set of already-processed event identifiers

Frequently Asked Questions

How is Webhook Verification calculated?

Verification score = 30 for ≥128-bit forgery resistance + timestamp tolerance score (20 at ≤60 s down to 0 above 15 min) + 16 replay cache + 12 constant-time compare + rotation score (10 at ≤90 days) + 8 TLS verification + 4 per-endpoint secret = 100. Forgery resistance is the weaker of the algorithm and the secret — HMAC-SHA256 over a 32-bit secret is a 32-bit problem — so the two are combined before scoring. A signature alone is not enough: without a timestamp and a replay cache, a captured delivery can be resent, which is why those two terms carry 36 points between them.

Why does Webhook Verification matter?

A webhook endpoint is an unauthenticated write path into your system, and the usual failures are comparing signatures with == and accepting any timestamp.

What values do I need to enter?

This calculator takes 9 inputs: Signature algorithm, Shared secret entropy, Timestamp tolerance, Replay cache keyed on event ID or signature, Constant-time signature comparison, TLS certificate verification on delivery, Unique secret per endpoint, Secret rotation interval, Peak delivery rate. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why is a timestamp needed if the signature is valid?

Because a valid signature stays valid forever. Anyone who captures one delivery — from a log, a proxy or a misrouted request — can resend it repeatedly. Signing a timestamp alongside the body and rejecting anything older than a few minutes bounds that window, and a replay cache on the event ID closes it.

You might also need