API keys leaking into the frontend

The browser is a public place. Anything in the JavaScript bundle, the HTML, or a NEXT_PUBLIC_ / VITE_ variable can be copied by someone who opens devtools. AI builders are good at making the demo work by putting the key next to the fetch.

Sort the keys

• Safe to ship, if the vendor says so and you have locked the other side down: a Stripe publishable key (pk_), a Supabase anon key with RLS on, a public analytics id.
• Never ship: Stripe secret key (sk_), Supabase service_role, OpenAI or Anthropic keys, Resend or other email keys, database URLs with a password, cloud secret keys, webhook signing secrets.
• If you are unsure, treat it as secret. A vendor page that says “publishable” or “client” is the exception, not the default.

Find them

• Search the repository for sk_, service_role, rk_live, whsec_, BEGIN PRIVATE, and api_key.
• Search the deployed site’s JavaScript. In the browser, open the network panel, filter for .js, and search the response. A secret in git history can also still be in an old chunk if the host cached it.
• Check the host’s environment screen. A variable prefixed for the client framework is public even if the dashboard looks private.

Move the call

• The browser asks your server. Your server holds the secret and calls Stripe, the model, or the email API. The user never receives the secret.
• Do not “hide” the key by encoding it, splitting the string, or fetching it from a public JSON file. That is the same leak with extra steps.

If one already leaked

• Rotate it at the vendor before you redeploy. Assume the old value is copied.
• Remove it from the client, from .env files that are committed, and from git history if it was pushed. Rotation without removal leaks the replacement.
• Check the vendor’s usage or logs for calls you did not make.

Not a guarantee. A search can miss a key that was built into an image, a source map, or a dependency. This is a checklist, not a forensic review.