Webhooks & Integrations
> Webhooks and "call this URL for me" integrations hand you a server-side HTTP client: you supply a > destination, the server connects to it. That makes them a first-class SSRF surface, a secret > leak surface (the server sends signing secrets/tokens to the URL), and sometimes an injection > surface (your payload lands in another tenant's pipeline).
§Where to look
- Webhook/callback URL fields, "notify URL", Slack/Discord/PagerDuty integration URLs, CI/CD
webhooks, OAuth redirect_uri and notification_url, RSS/feed importers, "test webhook" buttons.
§What to test
- SSRF: point the webhook at your collaborator, then at
169.254.169.254/internal hosts. Many
webhook senders follow redirects — host an allowlisted URL that 302s to the metadata service. See 0 and 1 .
- Secret leakage: capture what the server sends — signing secret, bearer token, internal
headers. A leaked signing secret lets you forge webhook events. (See 0 .)
- Redirect/parser tricks:
http://allowed@evil/,#,@, DNS rebinding to bypass a URL
allowlist (same bypass matrix).
- Injection into the consumer: if your webhook body is rendered in an admin/other-tenant UI,
it's stored XSS/HTML injection (see 0 ).
§Remediation
- Allowlist destination hosts; resolve-and-pin IPs; block link-local/private ranges; don't follow
redirects to new hosts; sign requests but never leak the secret to attacker-controlled URLs.