Leaked Stripe Restricted Key? Roll It Now

A Stripe restricted key lets whoever holds it call the Stripe API within the permissions it was given. It is narrower than a secret key, but it still reads and changes real payment data: customers, charges, subscriptions, refunds, payouts. Many integrations use one for a single job, such as a billing tool or a reporting script, and that job is often enough for an attacker to cause damage. Roll the key first, then check what it was used for.

Check your GitHub account for leaked secrets — free

Provider: Stripe
Severity: High
Impact: Payments and customer data
Checked live by LeakWatch: Yes

What a Stripe Restricted Key looks like

Stripe restricted keys start with rk_, then the mode (test, live or prod), then a long body of letters and digits:

rk_live_…XXXX   Stripe restricted key (masked)

The rk_ prefix is specific to Stripe restricted keys. The sk_ prefix belongs to full secret keys, which carry every permission on the account and are the more serious find. A pk_ value is a publishable key meant for browsers and is not a secret. If you see a whsec_ value, that is a webhook signing secret, a separate credential that lets someone forge events sent to your endpoint.

Mode matters less than it seems. A rk_test_ key cannot touch live charges, but test data can still reveal customer details, and test keys are often copied into production by mistake. Treat any restricted key as live until you have confirmed otherwise.

How Stripe Restricted Keys get leaked

Environment files committed by accident. A .env file with a STRIPE_RESTRICTED_KEY or similar variable, pushed to a public repository because .gitignore did not cover it.
Third-party integrations. Billing, accounting and analytics tools ask for a restricted key during setup. The key then sits in a configuration file or a shared spreadsheet that is later published.
Front-end code. A key placed in a JavaScript bundle or a mobile app. Anyone who downloads the app can read it.
CI logs and debug output. A pipeline that prints its environment, or a script that echoes the request headers it sends.
Shared snippets. A key pasted into a support thread, a gist or a blog post to show how an API call works.

What to do in the first hour

Roll the key in the Dashboard. Rolling creates a new value for the same key and lets you choose when the old value stops working. If the leak is active, pick an immediate expiry. Otherwise, give your deployment a short window.
Deploy the new value to your secret store or environment, and confirm the integration still works. Keep each restricted key tied to one job, so the next rotation is smaller.
Check the API request logs in the Dashboard, under the Developers section. Filter to the period since the key may have been exposed. Look for requests you did not make, unfamiliar IP addresses, bulk reads of customers, and refunds or payouts you do not recognize.
Review the key’s permissions. Open the key and compare what it can read and write with what the integration really needs. Remove write access you do not use. A reporting tool rarely needs to create charges.
Check the account for changes. Review recent refunds, new payouts, webhook endpoints and team members. An attacker who can change a webhook endpoint can receive your event data for as long as it stays there.
Look for other secrets in the same file or commit, especially full secret keys and webhook signing secrets. See I accidentally pushed an API key to GitHub.
Clean the repository. Remove the value from the current files, then decide whether to rewrite history. A deleted commit remains in the history of any clone, so the rotation is the real fix. For a wider search, see deep-scan your whole git history.

Not sure what else leaked? Run a free scan.

Revoke it at Stripe

Restricted keys are listed on the API keys page of the Stripe Dashboard, in the Developers section. Find the key by its name, then either roll it or delete it. Rolling is useful when the integration must keep running, because you can deploy the new value before the old one expires. Deleting ends access at once, which is the right choice when you know the integration is not in use. Make sure you are in the correct account and mode, since live and test keys appear in different views. A key you cannot find may belong to another account in your organization.

How LeakWatch detects it

The rule is called “Stripe Restricted Key”. It looks for the prefix rk_, then one of the modes test, live or prod, then at least 24 letters or digits, with word boundaries on both sides. Because the length is a minimum, longer bodies are still reported in full. A value with a different prefix, such as sk_ for a full secret key, is handled by its own rule. The severity is high, with the impact class for payment data. This type is checked live: LeakWatch can check whether a detected key is still active with a read-only request for the account balance. It does not create charges, read customer records or move money.

LeakWatch can check whether a detected key is still active with a read-only request to Stripe. It never reads your data or spends your credits.

FAQ

Is a restricted key as dangerous as a secret key?

Less, but not harmless. It only has the permissions you gave it, so an attacker is limited to the resources it covers. Those resources are often exactly the ones that matter, such as customers and refunds, so treat the leak as urgent.

Will rolling the key break my payments?

Only if the new value is not deployed before the old one expires. Set the expiry to a window you can meet, deploy, then confirm that a payment or a read still works. If the leak is active, the short disruption is worth it.

Do I need to check the webhook settings too?

Yes, if the same file held a webhook signing secret or if the attacker could have used the key to change endpoints. A forged webhook can make your system believe a payment succeeded when it did not. Review the endpoint list and the signing secrets after you roll the key.