# Leaked Stripe Restricted Key? Roll It Now > Stripe restricted key exposed on GitHub? Roll it in the Dashboard, check API logs and trim its permissions. Step-by-step guide for payment teams. Source: https://leakwatch.net/secrets/stripe-restricted-key --- [LeakWatch](/) [Product](/product)[Live feed](/leaks)[Guides](/secrets)[Blog](/blog)[Free scan](/) 1. [Home](/) 2. [Secrets](/secrets) 3. Stripe Restricted Key Payments · Secret guide # Leaked Stripe Restricted Key: what to do in the first hour High severityChecked liveLast verified October 23, 2026 · 5 min read 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: ```text 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 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. 6. **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](/blog/i-accidentally-pushed-an-api-key-to-github). 7. **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](/blog/deep-scan-your-whole-git-history). Not sure what else leaked? [Run a free scan](/). [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. ## Related - [Stripe secret key](/secrets/stripe-secret-key) - [Paystack Secret Key](/secrets/paystack-secret-key) - [Razorpay API Key](/secrets/razorpay-key) - [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github) - [Which vendors leak most this week](/leaks/trends) - [All secret guides](/secrets) [Get alerted next time a secret leaks — create a free account](/) LeakWatch is not affiliated with Stripe. ![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp) Gabriel Diyan (0xCr0c0) Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about). [GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab) LeakWatch Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about). Scan - [Product](/product) - [Live feed](/leaks) - [Trends](/leaks/trends) - [API docs](/docs) - [CI/CD](/docs?tab=ci) Read - [Blog](/blog) - [Secret guides](/secrets) - [Changelog](/changelog) - [About](/about) Verify - [Security](/security) - [Privacy](/privacy) - [Terms](/terms) - [Legal](/legal) - [Contact](/contact) - [Status](https://status.leakwatch.net) © 2026 LeakWatch [GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)