How to protect CRM and e-commerce webhooks from fake or duplicate events

A webhook is not merely a URL that receives data from an external platform. It is an entry point that can create an order, update a customer record, send a notification, modify inventory, or start an automation. If an event from an unverified source, a repeated event, or one with unexpected data is accepted, a useful integration can trigger improper business actions.

The issue requires combining technical and operational controls: knowing which provider can call, which events are permitted, which data are acceptable, and what specific consequence each message may have. The goal is not to block integrations, but to design them so that a failure, retry, or unusual notification does not automatically become an order, charge, status change, or false alert.

The risk: a notification can become a business action

In a typical integration, a payment gateway, e-commerce platform, CRM, or messaging tool sends a server-to-server notification to a dedicated endpoint. The receiver should not treat those data as trustworthy merely because they arrive from a known integration. OWASP identifies insecure consumption of APIs as a risk when an application places excessive trust in integrated services and reduces authentication, encryption, or validation controls for received data. [1]

For a hypothetical example, a store may receive a “payment confirmed” event and release an order without checking its authenticity, internal reference, or actual status. Another system could receive a customer creation notification twice and create duplicate records. The impact depends on the action connected to the webhook, so it is advisable to assess each endpoint as part of a business process rather than as a minor configuration detail.

Start with an inventory and defined scope

Before changing code or automation rules, prepare an inventory of webhooks. For each one, identify the sending provider, receiving URL, permitted events, target system, responsible person, authentication mechanism, and date of the last review. Maintaining visibility over APIs and their interfaces helps reduce issues resulting from an inadequate inventory or forgotten interfaces. [5]

Also define what each valid event can do. The fact that a notification is authenticated does not mean it should be able to modify any data. A delivery event should update only the intended shipping status; it should not create refunds, change prices, or alter permissions. This separation makes it possible to apply the principle of minimum effect: each message triggers only the action justified by its type and context.

• Document the provider, endpoint, responsible person, accepted events, and affected system.
• Indicate whether the event contains personal data, order references, or sensitive information.
• Establish a controlled shutdown path to temporarily stop an integration in the event of an incident.

Verify the origin before executing the action

The receiving route should use HTTPS and be dedicated to the webhook, without turning it into a generic entry point for multiple functions. Authentication should follow the mechanism documented by each provider: this may consist of a signature calculated over the request, a secret associated with the subscription, or a token. NIST recommends incorporating caller authentication and request and response validation as API protection controls. [2]

The verification must take place before business effects are triggered. Depending on the provider model, it may involve verifying a signature, timestamp, subscription identifier, or JWT elements such as its expiration, issuer, signature, and audience. Microsoft Graph describes these patterns for its notifications and states that the relevant validation must be completed before a notification is considered authentic. Secrets must be kept out of application code and protected appropriately. [3] [4]

• Reject requests that do not use the expected HTTP method.
• Compare signatures or secrets using secure mechanisms provided by the language or platform.
• Define request size limits and reasonable acceptance timeframes where the provider supports them.

Validate the content and make processing idempotent

A valid signature attests to the delivery mechanism, but it does not replace content validation. Check the event type, expected structure, required fields, formats, ranges, permitted values, and internal references before sending data to an ERP, CRM, WordPress, or order management system. OWASP recommends validating and sanitizing data originating from external APIs, since they must be treated as untrusted information. [1]

To prevent duplicates, record a unique event identifier, the provider, and the result of its processing. Before creating an order, issuing a ticket, or updating stock, check whether that combination has already been accepted. If it arrives again, log the attempt for investigation, but do not repeat the action. Idempotency must be designed into the receiving system, because senders may resend notifications after errors or timeouts. [4]

• Maintain a deduplication window appropriate to the lifecycle of each process.
• Link the event ID to the internal order, customer, or transaction reference.
• Handle repeated, invalid, and pending-review events separately to make them easier to track.

Separate reception from execution and retain useful evidence

Where the provider allows it, validate the notification quickly, store it in a controlled manner, and send it to a queue for later processing. This reduces the risk that a slow operation causes a timeout and a retry by the sender. Microsoft Graph, for example, recommends acknowledging or queuing notifications promptly and provides for retries when it does not receive a satisfactory response. [4]

Deferred processing does not eliminate controls: the worker that consumes the queue must reapply idempotency rules, validate the business context, and record the final outcome. Store the date, provider, event ID, authentication result, validation result, requested action, and internal reference. Avoid retaining full bodies if they include unnecessary tokens, secrets, or personal data. Test flows only in authorized environments, with documented test events or pre-production, including invalid signatures, unexpected formats, and controlled resends.

• Define who reviews failed or pending events.
• Alert on unusual increases in rejections, duplicates, or processing errors.
• Review the inventory and rules when the provider, endpoint, or business process changes.

Frequently asked questions

Is hiding the webhook URL enough?

No. An inconspicuous URL does not replace authentication or validation. The endpoint must verify the mechanism supported by the provider, accept only expected events, and limit the actions it can initiate.

Why do I receive the same webhook more than once?

Many senders retry a notification if they do not receive an adequate response or if a timeout occurs. The receiver must account for this with an event identifier, a record of processed events, and idempotent logic so that the business action is not repeated.

What should be reviewed after a webhook incident?

Review the available evidence: provider, event ID, time, authentication result, content validation, requested action, and internal reference. Then correct the specific rule, test the change in an authorized environment, and update the webhook inventory.