Review outbound webhook destination changes
Control where customer-configured callbacks can send data. Bind delivery jobs to reviewed endpoint versions and check DNS, redirects, secrets, and retries.
An outbound webhook endpoint is both a network destination and a data recipient. Review who can change it, which events it receives, and what a queued delivery does after that change. A URL that passed a save-time check can later resolve differently or be replaced before the worker sends private data.
OWASP's SSRF prevention guidance supports reviewing destination validation together with network restrictions. This endpoint-version worksheet adds an application-level record of who receives each event.
Bind the delivery to a configuration version
Create a versioned endpoint record rather than an untracked URL string. Keep its tenant, allowed event types, status, and signing-key reference together. Decide whether pending jobs retain the approved version or must be canceled when it changes.
| Change | Decision required | Test evidence |
|---|---|---|
| New destination | Authorized owner and permitted network target | Controlled validation result |
| Host changed | New recipient approval | Old jobs follow the recorded policy |
| Endpoint disabled | Stop future deliveries | Queued jobs cannot bypass disablement |
| Signing key rotated | Defined overlap and retirement | Recipient verifies the intended key version |
A delivery worker should not accept a replacement URL embedded in an event payload. Load the destination through the trusted endpoint record.
Recheck the network path at delivery
Review address resolution, connection setup, and redirect handling in the actual worker. Restrict schemes and ports to the product's documented needs. Do not allow a permitted public hostname to become a route into private infrastructure through unchecked resolution or a redirect.
Test with endpoints you control. Use a harmless event containing synthetic fields. Verify rejection before prohibited connections and confirm that error messages do not expose internal network details to the endpoint owner.
Constrain retries and recipient data
Set a retry schedule, maximum attempts, and a final disposition. A failing customer destination should not occupy workers indefinitely. Keep the payload limited to the subscribed purpose, and prevent destination URLs or credentials from entering general logs.
Include an endpoint-change race in the regression: queue a synthetic event, change the destination, and observe the documented outcome. Also test disablement between retry attempts. A complete review records both boundaries: the worker reaches only permitted network destinations, and each destination receives only the event data authorized for that endpoint version.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.