Symptom guide / Payments and credentials
Secret keys exposed in the browser
You find a key in downloaded JavaScript or a browser request and cannot tell whether it belongs there.
A browser must be able to read anything delivered to it. Renaming a variable or hiding a value behind a button does not make that value secret. However, not every provider calls its public client credential the same thing. Identify the key type before making changes so you do not confuse normal browser configuration with administrative access.
01 / Procedure
The two-minute check.
- Record where the value appears.
Open the live app in Chrome, choose Inspect and select Network. Reload, open the relevant JavaScript or API request and inspect Response or Headers. Note the file or request that contains the key. Do not paste the value into a search engine or public chat.
- Identify the provider and key type.
Open that provider’s key settings in your own dashboard and compare the label or prefix locally. For Stripe, pk_ keys are publishable while sk_ keys are secret. A webhook signing secret is a separate server credential, not a browser key.
- Check public-key protections.
For Supabase, an anon or publishable key is intended for client use, with row level security controlling data access. A service_role or secret key must stay server-side. For Firebase web config, inspect Security Rules instead of assuming the config’s API key authorizes private data access.
- Trace the privileged operation.
Find the browser action that uses the credential. Decide whether it should call your server instead. Record the operation and exposed file path so the repair removes the actual source of exposure, not only the one copied value.
02 / Evidence
Read the result.
WORKSOnly intended public configuration reaches the browser and access rules pass the two-account check.
BROKENA credential with server or administrative privilege is readable in the browser.
03 / Repair
Causes and fixes.
Ranked in the order to investigate, not by claimed frequency.
- A server credential was bundled into frontend code.
Revoke or rotate the exposed credential in its provider dashboard, move the privileged operation to an authorized server endpoint, and replace the deployed bundle. Treat removing the text without revoking the credential as incomplete.
- A public client key is mistaken for a secret.
Keep the intended public configuration and test the access rules with separate accounts. Rotating a public key does not repair a rule that lets strangers read private records.
- A build-time public variable contains a secret.
Move that value out of client-exposed configuration. In Vite, variables with the VITE_ prefix are exposed to client code; use that prefix only for values intended to be public.
04 / Limits
Edge cases.
- A secret may remain in an older downloadable build after you fix the latest one. Rotation invalidates the credential rather than relying on removing every old copy.
- Firebase keys used with other Google Cloud APIs may need additional restrictions. Follow the provider’s key-specific guidance instead of treating every API with the same rule.
When to stop and hand it over
Stop testing if the key has administrator privileges or can spend money. Rotate it and have access logs and affected operations reviewed. Send only the provider, key type and exposed path when requesting help, never the credential itself.
05 / Questions
Before the next attempt.
Does an environment variable automatically hide a key?
No. A frontend build can embed a value into downloadable code. The destination and framework exposure rules matter.
Was key exposure found in the notes case?
The recorded case was cross-user reading, not an exposed key. It is related evidence for testing the authorization boundary.