Secrets

Your Stripe key is on GitHub. Do this now, in this order.

6 min read · VibeSafe Blog

Deleting the file doesn't help. The key is still live until you rotate it, and it's still readable in git history until you remove it from there too. Here's the order that actually matters.

Step 1 (right now): rotate the key in Stripe

Go to dashboard.stripe.com/apikeys in live mode

Find the exposed secret key, open its overflow menu, and choose Rotate key. In the expiration dropdown, pick Now — not a grace period. A grace period exists to avoid downtime during planned rotations; it does the opposite of what you want during a leak, since it keeps the compromised key valid.

Copy the new key straight into environment variables

Server environment, CI secrets, and any deployment platform's secret store — never back into a file. Redeploy before you do anything else on this list.

This is the only step that actually disables the key. Everything below matters, but none of it neutralizes the leak by itself.

Step 2: check what happened while it was live

In the Stripe dashboard, check the API request logs for the exposed key — filter by key ID and look for requests you don't recognize, especially from unfamiliar IPs or at odd hours
Check for unexpected refunds, payouts, or customer list queries — a live secret key can read customer records, not just process payments
If anything looks wrong, Stripe support can help assess the blast radius; don't assume silence in the logs means nothing happened, but don't assume the worst either — check first

Step 3: remove it from git history

A key doesn't disappear from a repo when you delete the file and commit — it's still sitting in every commit before that one, retrievable with git log -p or a clone of the repo from before the deletion. If the repo is public or shared, treat the key as burned regardless of what you do next (that's what Step 1 was for), then clean the history so it stops being a liability going forward:

Use git filter-repo (the tool git.com itself now recommends) or BFG Repo-Cleaner to strip the key from every commit, not just the latest one
Force-push the cleaned history, and have every collaborator re-clone rather than pull — a stale local clone will just push the old history back
If the repo is public and has been up for more than a few minutes, assume it's already been scraped by an automated bot regardless of history cleanup — see the note on GitHub's secret scanning below

What GitHub does automatically — and what it doesn't

Stripe is one of over 100 partners in GitHub's secret scanning partner program. It runs automatically and free on public repositories: when GitHub detects a live Stripe key pattern in a public push, it notifies Stripe directly, and Stripe can revoke it — sometimes within minutes, before you've even seen the push notification.

Two things this doesn't cover, both worth knowing:

Private repositories aren't scanned by default. A key in a private repo can sit exposed indefinitely to anyone with access — a contractor after their contract ends, a compromised collaborator account, a fork nobody remembers exists.
There's still a window. Detection isn't instant, and a scraper watching public commits in real time can beat GitHub's own notification to Stripe. Rotating yourself in Step 1 is what closes that window — don't wait to see if GitHub catches it first.

Prevent the next one

Use restricted keys scoped to only what each service needs — a webhook handler that only needs to read charges shouldn't hold the full secret key
Add .env to .gitignore before the first commit, not after the first leak
Scan before you push, not after GitHub or a customer tells you

Scan your code for exposed keys free →

No signup · About ten seconds · Your code is never stored

FAQ

Does GitHub automatically revoke a leaked Stripe key?

Stripe is a partner in GitHub's secret scanning partner program, which runs automatically and free on public repositories. When GitHub detects a live Stripe key pattern in a public repo, it notifies Stripe directly, and Stripe can revoke it — sometimes before you notice the push. This does not cover private repositories, and there is still a window between the push and detection where the key is live.

Is deleting the file with the key enough?

No. Deleting the file and committing that change leaves the key readable in git history via git log or git show. The key must be rotated in the Stripe dashboard regardless of what you do to the repository — rotation is the only action that actually disables it.

Are restricted keys safer than the full secret key?

Yes. A restricted key scoped to only the operations your app needs (e.g. read-only on charges) limits what an attacker can do if it leaks. It does not prevent the leak, but it shrinks the blast radius.

What if the repo is private?

GitHub's automatic partner notification to Stripe applies to public repositories. A key in a private repo is not automatically reported, so it can sit exposed indefinitely to anyone with repo access. Rotate it regardless of repo visibility.

An honest note. VibeSafe flags hardcoded keys like this one before you ship — it doesn't monitor Stripe's logs or clean git history for you. Steps 2 and 3 above are still yours to do.