Stripe secret key (sk_live_, sk_test_, or rk_) is in the front-end code

What it means in plain English

Stripe's publishable key (pk_) is safe in the browser. A secret key (sk_live_ or sk_test_) and a restricted key (rk_live_ or rk_test_) are not. Stripe says only publishable keys are safe to expose, and that you should not put other keys in your application's code. Someone who loads the site can copy a leaked key and use the Stripe API with it.

Likely causes

• The AI put the secret key in a VITE_ or NEXT_PUBLIC_ variable so the browser could "call Stripe".
• A test key was left in the client, then the same pattern was copied for the live key.
• The key is hardcoded in a component instead of a server environment variable.

How to fix it, step by step

1. Search the built site's JavaScript for sk_live_, sk_test_, rk_live_, and rk_test_. A pk_ key can stay.
2. Delete the secret from front-end code. Stripe's key guide says not to put keys in application code. Put the key in the host's secrets vault, or in an environment variable that is not exposed to the browser, and call Stripe from a server route.
3. If the key was exposed, open the API keys page in the Stripe Dashboard and rotate or delete it, then create a replacement. Stripe says a compromised secret or restricted key should be revoked, and that code using an expired key can no longer make API calls, so update the server before you expire the old one.
4. Prefer a restricted key for the server. Stripe recommends restricted keys over an unrestricted secret key because you can limit what the key is allowed to do.

How to check it worked

• Search the deployed JavaScript again. The sk_ and rk_ values are gone.
• A server route can still create a Checkout Session or PaymentIntent. The browser only has the publishable key.

Sources

• https://docs.stripe.com/keys (opens in a new tab)