My Stripe secret key is exposed

Most leaked keys cost you money by being used. This one can move money that's already yours. That's a different kind of urgent, and it changes the order you do things in.

1. Which key is it?

Stripe puts the answer in the first few characters, which is genuinely helpful of them.

2. What a live secret key actually allows

It's worth being specific, because "someone has your Stripe key" covers a wide range of outcomes:

• Reading your whole customer list. Names, email addresses, billing addresses, payment history, the last four digits and card brand for every card on file. Not the full card numbers — Stripe never gives those back — but everything around them.
• Issuing refunds. This is the one that costs real money fastest. Refunds go back to the original payment method, so it isn't directly a theft route, but it can empty a balance and it takes your revenue with it.
• Creating charges. Against saved payment methods, with your account as the merchant of record. Your customers see your name on the statement, and your account wears the disputes.
• Changing payout settings on some account configurations — which is the theft route, and the reason to check it explicitly rather than assume.

3. Rolling it without taking payments down

Developers → API keys, then the ⋯ next to your secret key → Roll key. Stripe offers you an expiry window — 1 hour, 24 hours, or immediately — during which the old key keeps working alongside the new one.

That window exists so you can deploy without an outage, and it is a genuine trade-off:

• If the key was in a public repository: expire it immediately. An hour is a long time when scrapers find committed keys in minutes. A few failed checkouts is a cheaper problem.
• If it leaked somewhere narrower — a private repo, a screenshot in a Slack channel — take the hour, deploy the new value to every environment, then confirm the old one is dead.

Don't forget the places that aren't your app: staging, a CI secret, a Zapier or Make connection, a serverless function with its own environment settings, that one cron job on a VPS.

4. Replace it with a restricted key, not another secret key

Nearly every AI-built app uses sk_live_ — full account access — to do about four things: create a checkout session, read a session, handle a webhook, maybe list a customer's subscriptions.

Stripe lets you create a restricted key (rk_live_) with exactly those permissions and nothing else. Developers → API keys → Create restricted key, then tick only what your code calls. It's ten minutes of clicking, and it means the next leak — because there's usually a next one — is a much smaller conversation.

5. Checking what was done with it

Stripe keeps a proper audit trail, which makes this more tractable than most breaches. Cover the full window: from the commit that exposed the key to the moment you rolled it.

• Developers → Logs. Every API request, with the key used and the source IP. This is the definitive answer — if only your servers' addresses appear, nobody used it. Filter by the old key.
• Payments and Refunds. Anything you can't tie to a real order.
• Balance → Payouts. Confirm the destination bank account is still yours, and that no payout schedule changed.
• Customers. New customer objects you didn't create — a common shape of card-testing abuse.
• Developers → Webhooks. Endpoints you didn't add. An attacker who adds one gets a live feed of your business, quietly, long after the key is dead.

If you find anything at all: contact Stripe support and say plainly that a live secret key was exposed and you believe it was used. They deal with this weekly, they can see more than you can, and getting in early matters for how fraudulent charges are handled.

6. Where it usually leaked from

Across a couple of hundred public AI-built apps, live Stripe keys turned up in three recurring places — none of them the payment code itself:

• A "here's how to deploy this" markdown file. Real environment variables pasted into DEPLOYMENT.md or SETUP_COMPLETE.md so they could be copied into a hosting dashboard later. Markdown doesn't feel like code, so it doesn't feel like a leak.
• A test or seed script with the key inline, because it was faster than wiring up dotenv for a one-off.
• A frontend environment variable. VITE_STRIPE_SECRET_KEY and friends — anything prefixed VITE_, NEXT_PUBLIC_ or REACT_APP_ is compiled into the JavaScript bundle you ship. The .env file being gitignored makes no difference at all; the value is in the built output.

7. Keeping it out next time

• Secret key read from process.env on the server only, never a literal
• Never prefixed VITE_ / NEXT_PUBLIC_ / REACT_APP_
• Publishable key in the frontend — that's the one that belongs there
• Restricted key with only the permissions your code uses
• Webhook handler verifies the signature with whsec_, and treats an unverified event as hostile
• .env in .gitignore, and no real values in any committed markdown
• GitHub push protection on, so the next one is stopped before it lands

Paste this into whatever built the app:

Find every place a Stripe key appears in this repository, including markdown files, scripts, config and environment examples. Any secret key (sk_ or rk_) must be read from process.env on the server only — move any client-side usage into a server route. Confirm the publishable key is the only Stripe key reaching the browser bundle, and that every webhook handler verifies the Stripe signature before trusting the event. List every file you changed.