Fix guide · high · webhook_secret_generic

Generic webhook secret in client code

Why it matters

Most webhook providers (Linear, Discord-app, Vercel, Cloudflare, Notion, Clerk, Svix-powered services, Hookdeck, plus anything you self-host with a webhook surface) use the same shape: shared secret, HMAC signature in a header, you verify in your handler. The secret name in your code might be generic but the consequence is provider-specific — the leaked secret lets an attacker forge any webhook the provider would normally send.

If your code has multiple webhook integrations, the variable name doesn't tell us which one. Treat it as a leaked secret and verify against each.

How to fix it

1. Identify the provider. grep -B 5 -A 5 WEBHOOK_SECRET src/ will show the surrounding context (which API client, which import, which callback path) and let you identify which provider this secret belongs to.

1. Rotate at the provider's dashboard. Linear: Settings → API → Webhooks. Vercel: Settings → Webhooks. Discord App: Application → General → Reset webhook secret. Etc. The path varies but the action is universally "regenerate signing secret."

1. Audit your handler logs for forge-window activity. Same as the GitHub / Slack rotations — anything the handler did between leak and rotate needs review.

1. Remove the secret from source. git log -S, delete, push. Move to runtime config.

1. If you have multiple webhook integrations, use distinct env-var names per provider. STRIPE_WEBHOOK_SECRET, GITHUB_WEBHOOK_SECRET, LINEAR_WEBHOOK_SECRET — not a single WEBHOOK_SECRET shared across all of them. Distinct names also mean a single leak rotates one secret, not all of them.

Full guide: /blog/webhook-secrets-leaked.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.