Short answer: Some keys are meant to be in your website and some must never be. A Firebase apiKey, a Supabase anon or publishable key, and a Stripe pk_ key are public by design: your database rules do the protecting. A Supabase service key, a Stripe sk_live_ key, an OpenAI or Anthropic key, a cloud key or a database password in browser code is a breach: anyone can copy it and use it as you. If you find one, rotate it today and move the code that uses it to your server.
| Key | Looks like | In the browser? |
|---|---|---|
| Firebase web config key | AIza… | Fine, if your Security Rules are strict and the key is restricted in Google Cloud |
| Supabase anon / publishable | JWT with role anon, or sb_publishable_… | Fine, if Row Level Security is on |
| Stripe publishable | pk_live_…, pk_test_… | Fine |
| Supabase service key | JWT with role service_role, or sb_secret_… | Never: skips every database rule |
| Stripe secret / restricted | sk_live_…, rk_live_… | Never: can refund, pay out, read customers |
| AI provider keys | sk-…, sk-proj-…, sk-ant-… | Never: strangers run up your bill |
| Cloud and code keys | AKIA…, ghp_…, github_pat_… | Never |
| Database address with password | postgres://user:pass@… | Never: direct access to all data |
Here is how to tell the two apart and what to do about each.
Open the site, press F12, go to Sources (or Debugger) and search all files for the prefixes in the table. Also search your repository for NEXT_PUBLIC_, VITE_, REACT_APP_ and EXPO_PUBLIC_: every variable with one of those names is copied into the browser at build time.
Removing the key from the code is not enough. It is already in old builds, caches and your git history. Create a new key at the provider, switch your server to it, and revoke the old one. Then check the provider's logs or bill for use you don't recognise.
Anything that needs a secret key (charging a card, calling an AI model, writing as admin) belongs in an API route, a server action or an edge function. The browser asks your server; your server holds the key.
Restrict a Firebase or Google key in Google Cloud Console to your domains and the APIs you use. Write Firebase Security Rules that check request.auth, and consider App Check. For Supabase, check Row Level Security.
Turn on GitHub secret scanning and push protection, and run gitleaks over the repository's history once. Keep secrets in your host's environment settings, never in the code.
You can do all of the above by hand. If you'd rather start with a list of what's wrong, the vibeship quick check runs from outside, the way a stranger sees your site. The quick check is free and needs no account. It shows your grade and how many problems sit in each area; what each problem is and how to fix it is in the full report.
Yes, Firebase's own documentation says the web API key is not a secret. It identifies the project. What protects your data is your Security Rules, so check those, and restrict the key to your domains.
No. Anyone who loaded the site before still has it, and it stays in your git history. Rotate it at the provider so the old one stops working.
Only the ones that stay on the server. Variables starting with NEXT_PUBLIC_, VITE_ or REACT_APP_ are written into the browser code on purpose.
Fast. Automated scanners watch public code and websites for cloud and AI keys, and reports of abuse within minutes of a public push are common. Treat a leaked key as already used.
Sources checked on 25 October 2026.