Stripe whsec_ exposed — forged events are the real risk
whsec_ in client code lets anyone POST events your backend accepts as genuine. Find it fast — free scan of any URL.
Webhook secrets are the least dramatic-looking credentials with the most creative abuse potential. They do not read data or move money directly — they make your backend believe things that are false.
How signature verification works, how forgery exploits its absence, and why these leak.
What the Stripe webhook signing secret is
whsec_ values authenticate Stripe→you webhooks: Stripe signs payloads; your endpoint verifies against this shared secret before trusting contents like “invoice.paid” or “checkout.completed”.
whsec_FAKE000000000000000000000000Not an API key — often excluded from naive scanners’ lists, which is exactly why it survives audits unnoticed.
What it grants
Possession converts your fulfillment logic into an attacker-controlled oracle:
- Forge payment-success events → deliver goods without payment.
- Trigger state changes (subscriptions, entitlements) at will.
- Poison analytics/reconciliation quietly over time.
How it ends up in a bundle
Three arrival routes cover nearly every case we see:
- Local-testing snippets (.env with whsec_ + endpoint handler) merged wholesale into frontend bundles by mistake.
- Docs/tutorials pasted into client utilities “temporarily”.
- Config modules exposing every STRIPE_* var uniformly to both trees.
Does it belong in a browser?
Server-only by definition: verification happens where requests arrive, never in browsers.
Rotate it
dashboard.stripe.com/webhooks → rotate endpoint secret → update server env → confirm next delivery validates. Also verify raw-body reading — JSON-parsed bodies never verify correctly (a classic second bug).
Find it in seconds
Open DevTools on the deployed site and search the built assets for whsec_. If the search hits, the credential shipped; if it does not, check the chunks loaded on authenticated or interactive views, not just the landing page — the calling code often sits behind a route.
The faster path is to let a machine do the fetching. KeyDrift downloads the same JavaScript a visitor gets — HTML, every referenced chunk including ones named only in the route manifest, and the server-streamed data frameworks inline into the document — and reports credentials with a masked prefix, a fingerprint, and the exact file they live in. Paste your deployed URL into the scanner; no account needed.
Make sure it stays gone
It bears saying because it happens constantly: the fix holds until the next prompt that needs the query to return rows. Drift monitoring exists for precisely this — it diffs consecutive scans and pages you when a previously resolved finding reappears, naming the regression as a regression rather than repeating the first alert.
Why this failure class persists
It helps to name the economics honestly. Fixing this class of leak costs minutes when caught at deploy time and days when caught at invoice time, because by then the credential has been harvested, validated, resold or drained — often all four. Detection latency is the entire game, which is why the monitoring half of KeyDrift exists alongside the scanning half.
How KeyDrift reports this exact finding
When KeyDrift finds this on your deployment, the report shows a masked value (first 8 and last 4 characters only), a salted fingerprint for tracking, the exact chunk filename carrying it, and a severity with written rationale. Public-by-design neighbours — anon keys, publishable keys, Firebase web constants — appear as informational context rather than noise, because knowing what should be there is what makes the real findings credible.
Manual check, step by step
A five-minute version you can run anywhere: view-source on the landing page, copy every src= script URL, fetch each and search the results for whsec_. It misses manifest-only chunks and streamed payloads — which is precisely the gap between "I checked" and "it is clean" — but it catches the loud majority and builds the pattern-recognition that makes scanner output legible.
Close the loop with monitoring
Monitoring closes the loop that one-time verification leaves open. A scheduled scan refetches everything, diffs against history, and fires only on transitions: created, regressed, resolved. Regression alerts matter most here — they fire when a previously fixed finding returns, which in agent-era codebases is less a possibility than a schedule.
Common questions
Rotate breaks live webhooks briefly?
Update env immediately after rotation; gap is seconds when sequenced.
Scanner flagged it in a .map file?
Maps reconstruct original sources — same severity, different file.
Run a free scan at keydrift.dev/scan — paste a URL or the bundle source itself, no account. Findings arrive masked, with the exact chunk they live in.