Map the sender, receiving endpoint and business effect
Identify the actual event provider, account, environment and endpoint owner. Record which event types the integration needs and what each is allowed to change: an order state, CRM record, notification or other defined business result. A callback URL left from an old plugin or agency project should have a current owner and purpose before it receives new access.
Separate browser forms from server-to-server deliveries. They may use different authentication and request-defense mechanisms. A delivery that does not carry a browser CSRF token is not automatically insecure, but it still needs the provider's supported verification and the application's own business checks. Do not exempt unrelated user actions from protection merely because they share a server with a webhook endpoint.
Verify the exact provider-defined signature input before action
Use the provider's supported library and current verification procedure. Stripe requires the raw request body for its signature verification, so middleware that transforms the payload can change the input and cause failure. The configured endpoint secret and environment must match the received delivery. A secret API key and a webhook signing secret are not interchangeable simply because both are sensitive values.
GitHub documents its own signing scheme and safe comparison requirements. Use that guidance for GitHub rather than copy one provider's header, algorithm or payload rules to another service. Reject unverified deliveries before business effects. If verification fails, inspect the body-handling and configuration path using synthetic evidence instead of disabling the check to make the integration work.
Treat authenticity, freshness and duplicate effects as separate checks
A valid signature establishes the appropriate signed-message relationship under that scheme; it does not automatically establish freshness or that the business action should run again. Where the provider's scheme supports timestamps or replay checks, follow those controls. Track the appropriate event and business identifiers so repeated deliveries do not create unintended duplicate actions.
Stripe documents retries, possible duplicate events and lack of a guaranteed delivery order. Those are its documented behaviors, not a universal schedule for every sender. Design around the actual provider and integration. Decide how the application handles a repeated delivery, an older event and the latest object state, especially when several events can refer to the same order or customer.
| Stage | Control or evidence | Acceptance question |
|---|---|---|
| Delivery source | Provider, account, endpoint and environment. | Is this the integration the business approved? |
| Verification | Exact input, signature and matching endpoint secret. | Are invalid deliveries rejected before effects? |
| Event scope | Supported type, version and expected object relationship. | May this event change this business record? |
| Repeat and order | Processed-event and business-action records. | Does repeat or delayed delivery avoid unintended effects? |
| Processing | Validated durable receipt and accountable worker. | Can accepted work be recovered after a failure? |
| Outcome | Reconciled synthetic order or connected record. | Did the intended business result happen once as required? |
Validate the object and authorize the business transition
Check the expected event type, schema or version, environment and relationship to the business record. A signed event from an approved provider still needs interpretation. An event referring to another account, an unexpected object or a transition the application should not accept must not become permission to alter arbitrary records.
Decide which information is trusted from the event and when the provider's current object should be retrieved through an authorized API call. Keep account scope and credentials limited. Validate any configured outbound destination separately rather than let untrusted payload content choose where the server sends sensitive data. Verification of the incoming message is not a blanket authorization for every subsequent operation.
Acknowledge only after the accepted work is recoverable
Keep signature and basic validation before acceptance, then use an appropriate durable processing design for longer work. A quick success response should not discard the only event copy while the business action exists only in temporary memory. Define how a worker failure is retried and which operator notices work that remains unprocessed.
Use provider-supported synthetic events to test invalid verification, a permitted event, duplicate delivery and a controlled downstream failure where relevant. Record the delivery result and the application result separately. A successful HTTP response can mean the receiver accepted work without proving the CRM update or order transition finished. Reconcile the final business record rather than close the test at transport success.
Protect the lifecycle, evidence and maintenance ownership
Store signing secrets through the approved server-side arrangement and use the provider's supported rotation procedure. Record endpoint changes and environment ownership without exposing private values. Keep logs useful for tracing event IDs and failures while minimizing sensitive payload retention. Decide who handles a failed queue, repeated provider errors or an obsolete endpoint after a supplier departure.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with practical Israeli knowledge of websites, CRM connections and digital infrastructure. We can scope integration review and supported corrections with the application owner. The handover connects verified delivery, reliable processing and the accepted business outcome so an operational success code is not mistaken for complete correctness.
