Stripe secret key exposed in your frontend code: rotate it, then move it to the server

Why a secret key in the browser is a problem

Stripe's key guide lists which keys are "Safe to expose": the publishable key pk_... is the only one marked yes. A secret key sk_... "has unrestricted permissions on all Stripe APIs", and Stripe says that if someone else gets it, "they can make unauthorized charges, access customer data, or disrupt your integration."

Anything your site sends to the browser is public. Every visitor downloads your JavaScript bundle, and anyone can open the browser's developer tools and search it. Stripe's best-practices page says it plainly: "Never embed secret API keys in applications."

AI app builders produce this mistake easily: a prompt like "add Stripe checkout" can put the whole integration, secret key included, in front-end code, because there is no server in the project yet.

Fix it in this order

1. Rotate the key now. Stripe: "If a restricted or secret API key is exposed or compromised, rotate it immediately even if you aren't sure anyone saw it." In the Dashboard, open API keys, click the overflow menu (⋯) next to the key, choose Rotate key, pick an expiration, and copy the new value. Stripe's support steps then say to update your backend, check it works with View request logs, and delete the old key.
2. Move Stripe calls to the server. Anything that creates a Checkout Session, a PaymentIntent, a refund or reads customers must run in server code: an API route, a serverless function, or your builder's backend functions (for example Supabase Edge Functions or Firebase Cloud Functions).
3. Store the new key as a secret. Use your host's secrets or environment-variable settings, not a file in the repository. Many frameworks expose variables with a public prefix (such as VITE_ or NEXT_PUBLIC_) to the browser, so never give the secret key one of those names.
4. Keep only the publishable key in the browser. Stripe.js and Elements need pk_live_..., which Stripe says "It's safe to embed".
5. Check for misuse. Stripe's support page suggests reviewing the old key's recent activity in Workbench, refunding fraudulent charges and reversing unrecognized payouts.
6. Redeploy and look again. Search the deployed bundle for sk_live_ and rk_live_. Zero matches is the goal.

A server function that creates a Checkout Session looks like this (Node, Stripe's library):

// api/create-checkout-session.js  (runs on the server, never in the browser)
import Stripe from "stripe";
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY); // set in your host's secrets

export default async function handler(req, res) {
  const session = await stripe.checkout.sessions.create({
    mode: "payment",
    line_items: [{ price: "price_123", quantity: 1 }],
    success_url: "https://example.com/thanks?session_id={CHECKOUT_SESSION_ID}",
    cancel_url: "https://example.com/pricing",
  });
  res.status(200).json({ url: session.url });
}

Test this on a preview deployment before relying on it.

Use a restricted key on the server too

Stripe recommends restricted keys (rk_...) for most server code: "Restricted API keys help you limit the potential impact of a compromise." Give each one only the permissions that part of your app needs. A restricted key is still a secret and must stay on the server.

What Pewterkit Check looks at

The check reads your home page and the script files it loads, the same files any visitor downloads, and looks for live Stripe secret and restricted keys (sk_live_, rk_live_) along with other well-known secret formats (OpenAI sk-proj-, Anthropic, AWS, GitHub, Slack and SendGrid keys, Supabase service_role keys and private keys). It shows the key masked and names the file it was in. It never uses a key it finds.