Security Guides

Check who is allowed to call your webhook

Estimated Reading Time =

3 minutes

Technical Level =

Advanced

Threat Level =

High

Attack Type =

Other

Editorial illustration for check who is allowed to call your webhook

What you will learn

What you will learn

A webhook’s payload and familiar endpoint name do not prove who sent it. Validate the sender using its supported scheme, handle retries deliberately, and authorize the resulting business action.

A webhook is an automated message sent to your application when something happens in another service. For example, a payment provider may notify a shop about a transaction. Receiving a plausible message at the right address does not, by itself, establish who sent it or what action it should trigger.

Understand the idea

Use the sender’s supported verification method and validate the event for your own business process. Handle retries and repeated delivery so one event does not create the same payment or order twice. Keep the receiving service’s authority limited to the action it genuinely needs.

A simple way to follow the process
  1. Verify

    Validate the message through the provider’s documented method.

  2. Deduplicate

    Handle replay and retries according to the event model.

  3. Act

    Apply the intended authorization and transaction rules.

A practical example

Imagine a payment notification arriving twice after a network delay. The application verifies the provider’s message and checks whether that event has already been processed. It updates the order once, rather than treating each delivery as a new purchase.

Visual guide: Check who is allowed to call your webhook
Validate the message through the provider’s documented method. Handle replay and retries according to the event model. Apply the intended authorization and transaction rules.

What to do next

  1. Receive the request over the supported protected transport and bound its size and processing cost.
  2. Validate the signature and any documented timestamp or replay protections before trusting the event.
  3. Check the event type, expected account or tenant, and required business state.
  4. Handle duplicate deliveries using an appropriate event identifier or idempotent business operation.
  5. Queue longer work where suitable and return the provider's expected response behavior.
  6. Log outcome and correlation information without exposing the secret or unnecessary payload data.

How to check the result

Use the provider’s approved test tools to check valid, invalid, repeated, and delayed events. Record the verification and processing result without storing unnecessary sensitive payload information.

A legitimate event is delivered twice. Should both copies trigger payment?

Design the operation for the provider’s retry behavior. Use appropriate event tracking and transaction controls so a duplicate delivery does not repeat an unintended business effect.

Sources and useful guides

The following resources provide background and more detailed guidance. Use the sections that match your service and situation.

Scroll to Top