Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A webhook worker can turn a customer-supplied URL into a request from inside your infrastructure. This worked review follows registration, retries and network decisions to define safe delivery and the evidence needed before release.
This guide follows an illustrative invoice service that sends payment-status events to customer endpoints. The service and events are fictional; the review plan is a proposed exercise, not a customer incident or a claim that we ran these tests. Its purpose is to help an engineering team define what a safe delivery looks like and retain evidence when the implementation changes.
SSRF prevention starts with the delivery contract
Write down the feature’s intended behaviour before choosing validation rules. In this example, customers register an HTTPS endpoint, the service sends a signed event, and failed deliveries enter a bounded retry queue. The worker does not need arbitrary protocols, customer-controlled HTTP methods or access to internal administrative services.
Draw the complete request path: registration API, database, queue, worker, resolver, proxy and destination. Mark where a customer can change the URL after registration and which components can rewrite it. Include the operator’s redelivery button and any migration job that replays old events. A secure primary path does not establish that these secondary paths apply the same checks.
SSRF prevention must cover the connected destination
OWASP distinguishes integrations with known trusted destinations from features that must contact arbitrary external destinations. Its guidance addresses validation at both application and network layers, including resolved addresses and DNS-related risks. Use that distinction to decide whether a narrow destination allowlist is practical for your feature.
For the invoice example, propose a dedicated outbound delivery component rather than letting every worker choose its own transport rules. Define one parsing and destination-classification policy, then test it against the HTTP client actually used. Do not present a regular expression over the original string as the complete control. A URL parser, a resolver and a socket connection each answer different questions.
Review how the implementation handles multiple DNS answers and address changes between validation and connection. The acceptance question is whether the eventual connection remains within the approved destination policy. A design that checks one resolved address and then lets a second resolver independently choose a different address leaves that question unanswered. Prefer a reviewed transport or proxy that can enforce the policy at the actual connection boundary; document its hostname and certificate-validation behaviour.
Redirects and retries need their own release criteria
Decide whether the webhook protocol requires redirects at all. If it does not, treat a redirect response as a delivery result rather than following it automatically. If it does, require every hop to satisfy the same destination policy and limit the number of hops. Test both cases explicitly instead of assuming the client library preserves your intended boundary.
In the worked scenario, register an approved test receiver that responds with a redirect to the prohibited fixture. The expected outcome is no connection to that fixture. Observe both the delivery result and the fixture’s request log. A generic failure message from the worker is insufficient if it cannot establish whether the second request was attempted.
Now repeat the exercise through the retry queue. Change a registered destination between attempts, replay an older event and trigger manual redelivery. Decide whether an event uses a versioned destination snapshot or the current registration, and record that contract. Whichever choice you make, apply destination checks at delivery time and make policy-version changes visible in the test record.
Keep metadata controls and worker permissions separate
Cloud instance metadata deserves explicit treatment in the destination policy. AWS documents IMDSv2 as a session-oriented mechanism and explains that requiring tokens rejects requests without a valid token. This is useful protection for that metadata interface, but it does not establish that a webhook worker cannot contact other internal services.
Review the worker’s own access as another boundary. List the queue operations, signing material and storage permissions needed for delivery. Ask what an unexpected outbound response could expose or influence, and keep unnecessary credentials out of the worker environment. Treat this as a permissions review with an owner and evidence, rather than a reason to assume that destination validation can be relaxed.
Use a matrix that distinguishes denial from broken networking
Run the following proposed cases against controlled fixtures. Keep the same worker build, configuration and observable request path across the tests so the results can be compared. Add cases for features your implementation supports rather than treating this list as exhaustive.
| Case | Expected evidence |
|---|---|
| Approved HTTPS receiver | Receiver records the expected synthetic event and signature checks succeed |
| Prohibited destination fixture | Worker reports policy denial; fixture records no request |
| Redirect from approved to prohibited fixture | No follow-up connection to the prohibited fixture |
| Destination changed before retry | Delivery follows the documented versioning contract and rechecks policy |
| Slow receiver | Bounded attempt ends with a distinguishable timeout result |
| Oversized response | Response processing stops at the configured bound |
| Invalid certificate on controlled receiver | Delivery fails certificate validation |
| Resolver or policy service unavailable | Delivery does not silently bypass required checks |
First prove that the permitted case succeeds. If it fails too, the negative results may only demonstrate a broken network path. Capture a request correlation identifier, worker image digest, configuration version, fixture identity and timestamps. Redact event bodies, authentication material and customer endpoint query strings from the retained report.
Separate denied, allowed and inconclusive results. An empty receiver log can be useful evidence, but its completeness and collection window matter. Combine it with worker or proxy observations, and document what each source can establish. If the instrumentation cannot distinguish a policy denial from a connection failure, improve the test before describing the boundary as verified.
Make closure depend on the deployed delivery path
For a rollout, retain the test report alongside the proposed configuration and release identifier. Verify the deployed worker is using the intended version before closing the finding. Review failed deliveries after rollout for legitimate compatibility problems, and investigate those without broadly disabling the control. A support runbook should explain how to reproduce a customer’s delivery problem safely.
Key takeaways
- Define the permitted delivery behaviour before selecting destination-validation rules.
- Test redirects, retries and manual redelivery through the actual worker path.
- Pair negative cases with a successful positive control and retain observable evidence.
- Verify the deployed configuration before treating the finding as closed.
How SecurityVault approaches this
SecurityVault’s platform overview describes connected investigation across code, builds, images and workloads. That context can help a reviewer organise the relationship between a finding, its proposed fix and the deployed service. It does not replace a controlled webhook exercise or prove that every outbound request obeys your destination policy.
Keep the concrete acceptance criteria with the remediation work: which path was tested, which configuration was used and which results remain inconclusive. The useful question is whether the evidence supports closure for the deployed worker. Avoid converting a passing unit test into a broader claim about infrastructure that the test never reached.
Use the SAST remediation guide to connect the dangerous flow to a regression test, then use the deployment context to check where that fix runs. For a review of how these records fit your team’s workflow, contact SecurityVault with a synthetic example and the questions you want the evidence to answer.