What matters first
- Use the provider’s verification method and preserve the exact signed payload where required.
- Plan for retries and duplicate delivery without repeating a sensitive action.
- A valid signature does not replace application checks on account, amount, or state.
Verify the source before trusting the event
Follow the provider’s current signing and verification documentation, preferably through its maintained SDK. Signature schemes can depend on exact payload bytes, a timestamp, and a specific endpoint secret. Parsing or transforming the body before verification can break that relationship.
Stripe’s endpoint guidance illustrates the importance of raw-body handling and correct endpoint configuration. Treat provider-specific details as part of the integration contract, not a reason to copy a generic HMAC snippet into every webhook implementation. Different providers can use different signing rules.
References: [1] Stripe, [2] OWASP
Separate freshness from duplicate handling
If the signing scheme includes a timestamp or validity window, apply the documented check and maintain an appropriate system clock. A message can have a valid historical signature yet no longer be acceptable for a fresh action. Timestamp handling and secret rotation should be tested together.
Duplicate delivery is a separate issue. Providers may retry an event after a timeout or delivery failure. Store a suitable processing or idempotency record so repeated delivery does not create another refund, subscription change, or credit. Design the record around the actual business operation and its failure modes.
References: [1] Stripe, [3] OWASP
Authorize the business transition
After authenticating the message, establish which customer, tenant, order, and state it belongs to. Compare sensitive values with server-held records where the workflow requires it. A signed event should not be allowed to apply an unrelated account change simply because the endpoint trusts the provider.
Consider delayed or out-of-order events and concurrent processing. Define which state transitions are allowed and which require reconciliation. Queueing an event can improve delivery handling, but the worker still needs the context and checks required to perform the business action safely.
Review operational evidence and secret handling
Keep signing secrets in an appropriate secret store, limit who can change endpoint configuration, and document the rotation procedure. Avoid logging the secret or storing full sensitive payloads in a broadly accessible error dashboard. Retain event identifiers and outcome details that support investigation.
Test a valid event, a bad signature, an expired event where relevant, duplicate delivery, and a business-state conflict. Record the expected response and processing result. A webhook is ready for a security review when the team can explain both why a message is trusted and why the resulting action is permitted.
Your next steps
- Identify each provider’s signing contract and endpoint secret ownership.
- Verify payload handling, freshness policy, and duplicate-delivery behavior.
- Test sensitive account and payment transitions with provider test events.
- Book a scoped review of webhook trust and business-state boundaries.
Questions teams ask
Is an IP allowlist enough for webhook authentication?
It can be an additional control where supported, but use the provider’s documented message-authentication scheme and maintain the configuration as required.
Does a valid signature make every event safe to process?
It authenticates the signed message under the provider’s scheme. The application still needs account, tenant, state, and duplicate-processing checks.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .