Webhook Security Testing: Signatures, Replay, and Delivery

Short answer

Webhook security is not an IP allowlist. A receiver must verify the exact request content cryptographically, establish that an event is fresh, process legitimate redelivery without duplicate business effects, and prove that the event belongs to the right customer account. Follow the request from provider delivery through queues and workers to its final state change.

Webhooks connect payment, subscription, identity, and commerce systems. A flaw can result in a forged payment confirmation, account activation, duplicate refund, or cross-tenant data mix-up.

Map the trust boundary

For every integration, record the event producer, signing secret, bytes covered by the signature, tenant mapping, and services that run after verification. If one endpoint accepts an event, a queue stores it, and a separate worker applies it, verify that identity and integrity context survives each step.

Try to break signature verification

Confirm that the application verifies the provider-defined canonical input and raw body. Parsing and reserializing JSON can produce different bytes because of field order, whitespace, or number formatting. Capture a valid test request, then independently change a body field, signature, algorithm, and key ID. Every variant should be rejected without changing payment or account state.

The system must fail closed when verification middleware errors. Missing, malformed, or unknown-key signatures must not reach business logic. Keep secrets out of logs and error messages, and bound the overlap period for old and new keys during rotation.

Separate replay from retry

A replay is an attacker resending a request that was valid in the past. A retry is a provider redelivering the same event after a network failure. Replay a valid request inside and outside the acceptance window; confirm that the timestamp is signed and stale events fail. Try to create the same business effect with a different event ID too: event-ID checks do not replace payload integrity.

For legitimate retries, the idempotency record and business effect must be atomic. Marking an event complete before processing can lose it; recording completion late can create a duplicate refund. Prove that a transaction, durable inbox, or queue design closes both failure windows.

Tenant and URL boundaries

A tenant_id, account_id, or customer_id in the body is not authorization evidence. The server should resolve which merchant or installation owns the signing key and map the resource to that record. Test Tenant B’s resource with Tenant A’s key, deleted integrations, rotated keys, and test-versus-production confusion.

Customer-configured callback URLs create a separate SSRF risk. Review redirects, DNS changes, private IPs, metadata endpoints, and protocol restrictions. Do not rely only on an initial DNS check; constrain the actual connection destination as well.

Retest checklist

• Invalid signatures cause no side effects.
• Stale requests fail; legitimate retries create one business effect.
• Cross-tenant mappings fail.
• Queues, workers, and manual replay use the same trust model.
• Logs support investigation without exposing secrets.

Operational resilience and evidence

Correct signature verification is only one part of safe processing. Check what happens when a queue fills, a worker restarts, or a provider retries for an extended period. The system should neither lose accepted events nor apply the same event repeatedly. Manual replay from a dead-letter queue must not create a bypass around the normal receiver; operator actions should be authenticated, authorized, and auditable.

A useful finding states which field was changed in a test account, which control failed, and what business state changed. “Signature validation is missing” is not enough. For payments, use a sandbox transaction or controlled test object instead of causing a real charge. Classify the demonstrated impact precisely: forged event acceptance, duplicate processing, cross-tenant routing, or secret exposure.

For monitoring, provider event ID, integration identity, tenant, verification result, and processing status provide useful correlation without logging signatures or secrets. Alert on unusual event repetition, increased signature failures, unexpected tenant mappings, and queue items that remain incomplete. This keeps the control observable throughout the integration lifecycle, not only during an assessment.

A 2xx response from a webhook endpoint is not proof of security. Retesting should prove that rejected events do not change state and accepted events produce one effect for the correct account. For a broader API review, see our API security assessment.