Webhook and URL Consumer Boundaries
Map validation, storage, resolution, redirects, and delivery for features that accept or derive a remote URL.
Every step requires authorization. Review side effects before running commands against a live system.
Define the boundary before the test.
- Preconditions
- Current scope, observed technology, reachable feature, controlled identities or data, and a recovery plan.
- Expected evidence
- One observable response, state, or callback that distinguishes the hypothesis from normal behavior.
- Negative control
- The same action with the security-sensitive variable removed, replaced, or bound to its rightful owner.
- False-positive checks
- Cache, retry, race, reflection, proxy rewriting, stale sessions, and unrelated asynchronous activity.
- Chain gate
- Record the proven primitive and the next missing prerequisite. Do not expand impact until scope and authorization still permit the next step.
Classify the consumer
Determine whether the feature validates, previews, fetches, stores, retries, signs, or delivers to a URL. Separate webhooks, OAuth callbacks, avatars, imports, link unfurling, proxy endpoints, remote media, and document renderers because they have different expected methods and trust boundaries.
Capture the direct request shape
Configure ingestion redaction before testing. Point one controlled record at a unique private-listener token, then retain only protocol, method, redacted path, body length, coarse source, retries, and timing needed for proof. Drop authorization, cookie, signature, and customer-data fields at ingestion. Keep any necessary raw event only in a private, bounded, access-controlled log and never place it in a report.
https://hook-021-direct.UNIQUE.oast.example/receiveBuild a one-variable parser matrix
Compare scheme case, explicit default port, trailing dot, userinfo, fragment, encoded delimiters, and a scheme-relative form only when each still resolves to your controlled destination. Record accepted validation separately from an observed outbound request.
https://[email protected]/receiveCompare save-time and delivery-time checks
Some systems validate when the URL is saved but resolve or redirect later when a job runs. Use fresh tokens for save, test-delivery, real delivery, retry, and update actions. Do not use DNS rebinding or internal destinations unless the live policy explicitly authorizes that separate test.
Test controlled redirects only
If allowed and supported, use one controlled redirect from token A to token B and compare it with a direct request. Record which headers and methods survive. Never point the second hop at a third party or an internal address.
Report the exact boundary
State whether you proved validation bypass, outbound resolution, HTTP delivery, redirect following, retry behavior, header disclosure, or cross-tenant triggerability. These are separate primitives and should not be collapsed into a generic SSRF claim.
Common guidance
- A webhook sending expected application data to a user-configured URL may be intended behavior. The security question is who can configure it and what data or network boundary it crosses.
- Store-time acceptance is not proof of delivery. A DNS event is not proof of HTTP delivery.
- Signing secrets and authorization headers may appear at the listener. Redact them and never reuse them.
- Use dedicated test tenants and records when delivery could include real user data.
Mapped workflow tools
References
- https://portswigger.net/web-security/ssrf ↗
- https://portswigger.net/web-security/ssrf/blind ↗
- https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html ↗
Version history: normalized permanent page created 2026-08-20.