Webhook security testing: signatures, replay, and delivery state

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

Webhook security testing should distinguish authentic delivery from safe processing. A valid provider signature establishes one property; it does not by itself prove that an event is fresh, belongs to the intended account, or is applied only once.

OWASP documents receiver authentication and replay considerations for webhook integrations. OWASP Webhook Security Cheat Sheet provides the underlying reference. The assessment design below is an original defensive example, not a report of a customer incident.

Describe the receiver's trust decisions

List the webhook provider, receiving environment, allowed event types, expected account, and downstream state changes. Document which secret or key authenticates delivery and who can rotate it. Keep test and production configurations separate. Ask whether the application verifies the original body before parsing or transforming it, and where the verification outcome is logged. These are integration-specific questions, so an assessment should follow the provider's current protocol rather than assume every webhook uses the same signature format.

Use a sandbox lifecycle scenario

In the provider's supported sandbox, create a disposable subscription or order that has no financial value. Exercise a genuine event, then use the provider's test or redelivery facilities to evaluate duplicate handling and event ordering. Include a stale-state case, such as an earlier status arriving after a later update. Keep all callbacks on owned endpoints and use documented rate limits. No forged production payment or credential harvesting is required. The scenario should end with one predictable application state and a traceable delivery history.

Preserve processing evidence

Capture the provider event identifier, account context, verification result, receipt time, processing outcome, and final synthetic object state. Redact delivery secrets and signatures from broadly accessible reports. Check what happens when a handler acknowledges delivery before its worker finishes: a successful HTTP response may mean only that a queue accepted the event. If the worker fails, identify the retry and reconciliation path. Distinguish duplicate delivery from duplicate business execution, because the former is often part of normal integration behavior.

Retest failure paths as well as success

A fix should preserve legitimate retries while preventing repeated state changes. Evaluate key rotation, unknown event types, account mismatch, and a temporary downstream failure within the agreed sandbox. Include operational ownership in the report so an on-call engineer can reconcile stuck events. This test does not prove the provider's entire delivery system is secure. It establishes the observed receiver behavior for selected event types and lifecycle states. For payment-specific business decisions, also evaluate the separate checkout-to-fulfillment mapping.

A useful assessment artifact

Keep a delivery-state worksheet showing received, verified, queued, applied, failed, and reconciled outcomes for the synthetic event. That worksheet helps support teams investigate incomplete processing without treating every retry as suspicious or every acknowledgement as completed business work.

Plan an assessment

Discuss the authorized scope and required evidence with FailSafe SWARM. For a business evaluating an initial engagement, review the first-pentest offer and confirm scope before purchase.