Webhook Site

webhook.site

Hosted OAST collector + request inspector. Visiting webhook.site mints a unique token of the form https://webhook.site/<uuid>; every HTTP request and DNS query (via the matching *.dnshook.site subdomain) to that token is recorded with full headers, body, source IP, geolocation, and timing, and surfaced in a Web UI, JSON API, and (with whcli) a CLI stream that can forward or execute on each event.

Use it as the public callback endpoint for any blind vulnerability class, OAuth/SAML round-trip inspection, webhook integration debugging, or a temporary HTTPS relay into a local service during authorized engagements.

Scope Guard

• Confirm authorization in writing before pointing any target application, OAuth flow, or callback at webhook.site. Captured requests can contain tokens, cookies, PII, and credentials.
• Treat the token URL like a secret — anyone who knows it can read every request. Use the "Protect with password" / "Login required" features on paid plans for sensitive captures.
• For long-running or multi-operator engagements, use a paid token (persistent, higher limits) or self-host the open-source webhook.site server on owned infrastructure.
• Free anonymous tokens expire after 7 days of inactivity and cap at 100 requests / 10 MB body — fine for OAST PoCs, not for sustained collection.
• Webhook.site is third-party SaaS: the operator (Simon Fredsted / webhook.site GmbH) sees every payload. Do not route customer production traffic, regulated data, or live credentials through it without a contractual agreement.
• For DNS exfil that must not transit a third party, prefer self-hosted interactsh or an authoritative server you control.

When to Pick webhook.site

Concepts

• Token: a UUID that owns a callback URL https://webhook.site/<uuid>. Created automatically when you open the homepage in a browser, or programmatically via POST /token.
• DNSHook: every token has a matching <id>.dnshook.site subdomain (<id> derived from the UUID). Any DNS query to <sub>.<id>.dnshook.site is captured.
• Email: every token also has <id>@email.webhook.site for inbound email capture.
• Custom Actions (paid): per-token rules that modify the response, forward the request elsewhere, transform the body, or conditionally branch. Effectively a tiny serverless dataflow over the captured traffic.
• API key: a per-account secret sent as the Api-Key HTTP header. Lets whcli and scripts create tokens, list/read requests, manage custom actions, and forward without anonymous rate limits.
• Whitelist IPs: outbound traffic from webhook.site (and Custom Action forwards) originates from 178.63.67.106, 178.63.67.153, 2a01:4f8:121:114d::/64, 2a01:4f8:121:11a5::/64. Open these on your target firewall when forwarding from webhook.site into an internal collector.

Quick Starts (Web UI)

1. Open https://webhook.site → page is now bound to a new token URL shown at the top.
2. Trigger the callback (paste the URL into the target form, payload, OAuth redirect_uri, SSRF probe, etc.).
3. Inspect each captured request in the left pane: method, headers, raw + parsed body, source IP, country, user agent, timing.
4. Use Edit to change the default 200 response (status code, headers, body, content-type, delay) when the target expects something specific.
5. Use Copy for the unique URL, <id>.dnshook.site host, or <id>@email.webhook.site address.
6. Optional: "Login required" on the token page to gate UI access (paid).

Quick Starts (CLI — whcli)

# Install via Node (preferred for `forward`/`exec`)
npm install -g whcli

# Or via Docker
docker run --rm -it ghcr.io/webhooksite/whcli:latest --help

# Stream a token to the terminal
whcli forward --token=<UUID>

# Forward every captured request to a local web service
whcli forward --token=<UUID> --target=http://127.0.0.1:8080

# Forward only requests whose query string matches ?op=cb
whcli forward --token=<UUID> --target=http://127.0.0.1:8080 --query='op=cb'

# Run a local command per request (the raw request body is piped to stdin)
whcli exec --token=<UUID> --command='/usr/local/bin/handle.sh'

# Auth (paid plans / private tokens)
export WH_API_KEY='...'
whcli forward --token=<UUID> --target=http://127.0.0.1:8080

whcli keeps an HTTP long-poll / websocket open against https://webhook.site and replays every captured event locally — turning a public token into a real local listener without exposing your machine.

Quick Starts (JSON API)

Base URL: https://webhook.site. Authenticate scripted access with Api-Key: <YOUR_KEY>.

# Create a new token (returns JSON with uuid, alias, default-content, etc.)
curl -s -H 'Api-Key: '"$WH_API_KEY" -H 'Content-Type: application/json' \
  -d '{"default_status":200,"default_content":"ok","default_content_type":"text/plain"}' \
  https://webhook.site/token | jq .uuid

# List captured requests (paginated, newest first)
curl -s -H 'Api-Key: '"$WH_API_KEY" \
  "https://webhook.site/token/<UUID>/requests?sorting=newest&per_page=50" | jq '.data[] | {ip,method,url,query}'

# Read one request's raw body
curl -s -H 'Api-Key: '"$WH_API_KEY" \
  "https://webhook.site/token/<UUID>/request/<REQ_UUID>/raw"

# Delete all requests for a token
curl -s -X DELETE -H 'Api-Key: '"$WH_API_KEY" \
  "https://webhook.site/token/<UUID>/request"

Body size limit: 10 MB per request (free); contact provider for paid tier limits.

OAST Playbook

The point of webhook.site is to confirm "did the target side-effect actually fire". Pick the channel that the vulnerability class can reach.

Tips:

• Encode a unique marker per probe (?id=<host>-<param>-<timestamp>) so multi-target campaigns can attribute callbacks.
• DNS exfil: chunk data with base32 (DNS-safe) into labels, max 63 chars each, max 253 total: <chunk>.<chunk>.<id>.dnshook.site.
• Use Custom Actions to auto-forward only callbacks matching a query/header pattern to your internal collector, ignoring scanner noise.

Custom Actions (Paid)

Per-token rules evaluated on every inbound request. Useful primitives:

• Set response — return a specific status / headers / body to coerce the target into a follow-up request (e.g. 302 redirect chain for OAuth abuse, JSON shape for webhook contract tests).
• Forward — relay the request to an internal URL (honor the webhook.site outbound IP whitelist). Effectively turns the token into a public-facing reverse proxy.
• Modify — rewrite body / headers / URL via templating before forwarding.
• Conditional — branch on request properties (method, header, query, JSON path) so the same token serves multiple workflows.
• Stop — short-circuit further action evaluation.

Combine actions to build small dataflow pipelines (e.g. "if X-Phish-Token header present, forward to internal collector; else return 200"). For complex transforms prefer whcli forward --target to a local service you fully control.

Hardening Checklist

• Use a per-engagement token; rotate after the engagement to invalidate any payloads that escaped scope.
• Set a non-trivial default_content and content-type — some targets behave differently when the callback returns HTML vs JSON vs empty.
• On paid plans, enable "Login required" or password-protect the token before sending the URL to anyone outside the operator team.
• When forwarding to internal services (Custom Actions or whcli forward), require an Api-Key-style shared header so only webhook.site traffic is honored.
• Open OS firewall rules only for the webhook.site source IPs (178.63.67.106, 178.63.67.153, 2a01:4f8:121:114d::/64, 2a01:4f8:121:11a5::/64) on the internal collector side.
• For high-stakes captures (production credentials, regulated data), self-host the open-source webhook.site server or use interactsh on owned infrastructure.
• Treat captured bodies as evidence: export via API into the engagement ticket, then purge the token (DELETE /token/<UUID>/request).

Troubleshooting

Resources