Webhook Security Testing: SSRF, Auth Bypass, and Replay Attacks
Webhooks turn your app into an HTTP client. That means classic server-side request forgery (SSRF), plus webhook-specific failures: no signature verification, replayable payloads, and open callback URLs that anyone can hit.
Map the webhook surface
- “Add webhook URL” in project settings
- CI / billing / chat integrations
- Outbound “notify me” features
- Inbound webhook receivers (
POST /hooks/...)
Test both directions: what the app calls, and what it accepts.
Outbound SSRF checks (authorized targets only)
- Point the webhook at an endpoint you control.
- Confirm the server fetches it (your access logs).
- Try URLs the program allows for SSRF labs — metadata IPs only if explicitly in scope and safe.
- Watch for redirects, DNS rebinding protections, and scheme allowlists (
file:,gopher:).
Never scan internal corporate networks outside scope.
Inbound receiver checks
- Can you forge events without a valid HMAC signature?
- Does the app accept replays of an old signed body?
- Is the signing secret predictable or exposed in JS?
- Are different customers’ webhook secrets isolated?
Impact
- SSRF toward cloud metadata or internal admin panels
- Spoofed “payment succeeded” events
- Cross-tenant event injection
Report structure
Separate outbound vs inbound. Include callback logs, signature bypass proof, and a suggested fix (HMAC with timestamp + secret rotation).
Defensive checklist
- Allowlist schemes/hosts for outbound webhooks.
- Block link-local and cloud metadata ranges.
- Require HMAC signatures with timestamp skew limits.
- Make receivers idempotent; reject replays.
- Store secrets server-side only; rotate on leak.
Webhooks are SSRF with a product name. Treat every callback URL as attacker-controlled until proven otherwise.
Original Bugflare guide informed by PortSwigger SSRF methodology applied to webhook features.