Critical: act in the next 60 seconds

Stripe restricted key (rk_live_) leaked: scoped damage, real fix

Your Stripe restricted key may be exposed. Here is the fastest possible recovery — three steps, no theory.

  1. Step 01

    Identify the restricted key in Stripe Dashboard and view its permissions before deleting.

  2. Step 02

    Delete the key. Create a new restricted key with the same minimal permission set.

  3. Step 03

    Audit logs for any actions within the leaked key’s permission scope.

Step 01 — Revoke

Kill the leaked credential first

Developers → API keys → Restricted keys section → click the leaked key → Delete. Confirm. Create a new one with "Custom permissions" matching the minimum your service needs.

Open Stripe API keys

Step 02 — Rotate

Update the new key in the right place

Server-side env vars only — never in client code, never with NEXT_PUBLIC_.

Use restricted keys per integration
// One restricted key per microservice/integration.
// e.g. webhook-handler can only Read PaymentIntents.
const stripe = new Stripe(process.env.STRIPE_RK_WEBHOOKS!);

Step 03 — Scan

Confirm nothing else leaked alongside it

Find every other API key sitting in your bundle or env-file exposure with one scan.

How this usually leaks

  • 01Logged to a server file accessible at /logs or /actuator.
  • 02Embedded in a config.json deployed to a public path.
  • 03Committed to a Postman collection or .http file.

FAQ

Frequently asked questions

Do restricted keys need rolling if only the master leaked?
No — restricted keys are independent of the master. But if your env file leaked, every key in it is compromised regardless of type. Rotate them all.
How do I know what permissions the leaked key had?
In the Stripe Dashboard, click the key. The "Permissions" tab shows exactly which resources and actions the key could access. Audit logs in those areas for the past 30 days.

See what else leaked in the same deploy

Free scan. 70+ checks. Results in 60 seconds.