← BlogKey leaked3 min readUpdated 2026-08-03

Stripe secret key leaked: immediate steps

This one touches real money and real customer data. Roll the key before you read the rest.


1. Rotate it now

Revoke and reissue in the Stripe dashboard

  1. 1Open dashboard.stripe.com/apikeys.
  2. 2Find the exposed secret key and choose Roll key. Stripe lets you set a short grace period — pick the shortest your deploy can tolerate, or expire immediately if you can deploy now.
  3. 3Update the key wherever your server reads it, then deploy.
  4. 4Confirm the old key is expired, not just replaced.

Console: https://dashboard.stripe.com/apikeys

2. What someone can do with it

  • Create charges, issue refunds, and move money — a refund to an attacker-controlled destination is the common play.
  • Read your full customer list: names, emails, addresses, and the last four digits and expiry of saved cards.
  • Create and cancel subscriptions, and read your entire payment history.

3. Check whether it was already used

Look for activity you did not cause

  1. 1Open the Stripe dashboard → Developers → Logs and filter to the period since the key was exposed.
  2. 2Look for API calls from IP addresses that are not your servers.
  3. 3Check Payments and Refunds for anything you did not initiate — refunds especially.
  4. 4Review Connected accounts and webhook endpoints for entries you did not create.

4. Find out how it leaked

Stripe publishes two keys and they are easy to confuse. pk_live_… is the publishable key and belongs in your frontend. sk_live_… is the secret key and must only ever exist on a server. If you find sk_live_ anywhere in client code, that is the leak.

Paste this into Cursor, Claude Code or your builder
Find every hardcoded credential in this project and move it out of the code.

1. Search all files — including client code, config files, and anything
   already committed — for hardcoded secrets: Stripe keys, plus
   any string starting sk-, sk_live_, AKIA, ghp_, or variables named
   *_SECRET, *_TOKEN, *_API_KEY.
2. For each one, tell me the file, the line, and whether that code runs in
   the browser or on the server.
3. Move every real secret to a server-only environment variable. Do NOT
   use a client-exposed prefix (VITE_, NEXT_PUBLIC_, REACT_APP_) — those
   are compiled into the browser bundle.
4. Any provider call that needs the secret must happen server-side; change
   the frontend to call my own endpoint instead of the provider directly.
5. Check whether the secret is in git history, not just the current files.
   If it is, say so — removing it from HEAD does not remove it from history.

Give me a list of every secret found, where it was, and what you changed.

This is one check out of 40+

Paste your site address and we run the whole list from the outside — leaked keys, open databases, unprotected pages — then hand you one prompt that fixes what we find. Free, about 30 seconds, no signup.

Check my site — free