Webhook security: signatures, replays and duplicate events

A webhook is an external request

A webhook lets another service notify your application about an event. An endpoint that accepts a request is not automatically proof the event came from the provider. Public reachability makes independent verification particularly important when events change payments, access or records.

Verify before acting

Follow the provider’s current signature-verification instructions and use its maintained library where available. Many schemes verify the original request bytes, so parsing and rewriting the body first can break verification. Keep signing secrets private and support rotation.

Handle repeats deliberately

Providers may retry a legitimate event. Attackers may also replay captured requests. These are related but different problems.

• Apply the provider’s timestamp or replay checks where supported
• Use a durable event identifier to prevent duplicate side effects
• Handle events arriving out of order
• Record acceptance before acknowledging work that must persist
• Keep processing failures observable without logging secrets

Check the business state too

A valid signature does not remove the need to verify which account an event belongs to and whether a transition is allowed. For a high-impact operation, confirm relevant state with the provider where its workflow calls for this, rather than trusting every submitted field.

Outbound callbacks need another boundary

If customers can register a URL your service will call, review server-side request forgery risks. Constrain schemes and destinations, block internal network targets and control redirects. Agree safe test cases with the team before assessing these fetches.