Stop 24 of 42 · The Vault · Secrets in the browser

The combination printed on the brochure

The bank prints a glossy brochure for every visitor. Someone helpfully included the vault combination “so the website can use it”. Every visitor, including Mallory, gets a copy. Brochures are for public information; the combination belongs in the back office.

The VaultSources checked 25 Oct 2026

Watch it happen

Play it as

The vault combination is printed in the customer brochure. Mallory reads it and opens the vault.

Arrival

Alice and Mallory both walk into the public lobby. The bank hands every visitor a brochure (your website’s JavaScript).

1 / 5

In bank terms and app terms

In the bank	In your app
Customer brochure	Your front-end JavaScript bundle and any NEXT_PUBLIC_ / VITE_ variables
Vault combination	Secret API keys, service-role keys, database passwords
Public address on the brochure	Publishable keys (Stripe pk_, Firebase config, Supabase anon key with RLS on) designed to be public
Back-office teller	Server routes, API handlers or edge functions that hold the secret

Are you exposed?

You might be exposed if…

A secret is read from a variable starting with NEXT_PUBLIC_, VITE_ or REACT_APP_.
Your browser Network or Sources tab shows keys such as sk_live_, service_role, sk- (OpenAI) or an admin SDK credential.
The front end calls a paid third-party API (OpenAI, Twilio, SendGrid) directly with your key.

What to do about it

Move every secret call into a server route, and let the browser call your route instead of the third party. Require login and add rate limits on that route so it is not an open relay for your key.
Use only keys designed to be public in the browser, and pair them with rules such as Supabase RLS or Firebase security rules.
If a secret ever reached the browser, rotate it immediately; deleting it from the next deploy is not enough.

Track these in your to-do list →

Ask your AI tool to fix it

Paste this into Cursor, Claude, Lovable, Bolt or whatever you build with.

Prompt

Search my front-end code and build output for secret keys exposed to the browser, including variables prefixed NEXT_PUBLIC_, VITE_ or REACT_APP_. For each real secret (service-role keys, sk_ keys, OpenAI/Twilio/SendGrid keys), move the call into a server-side API route, read the key from a server-only env var, and tell me which keys I must rotate. Leave genuinely public keys (Stripe publishable, Supabase anon) in place.

Where this comes from

The facts, figures and fixes on this page were checked against these sources on 25 Oct 2026. They are linked so you can check for yourself.

How to use environment variables in Next.jsNext.jsNEXT_PUBLIC_ variables are inlined into the browser bundle for everyone to read
Env Variables and ModesViteOnly VITE_ variables reach client code, so never put sensitive values in them
API keysStripePublishable keys (pk_) are for the browser; secret keys (sk_) must stay on the server
API keysSupabaseservice_role must never reach the browser; the anon key is public and relies on RLS
Row Level SecuritySupabaseRLS is what makes the public anon key safe to ship in front-end code
Learn about and manage API keys for FirebaseFirebaseFirebase config keys are meant to be public; Security Rules protect the data
Secrets Management Cheat SheetOWASPRotate any secret that has been exposed; keep secrets server-side

Spot a mistake or something out of date? Report a correction · How these guides are made and checked

Go deeper in isitsecure

The free, open-source scanner checks for most of the problems in these guides.