Why Your Frontend API Keys Are Not Secret

Quick answer
Anything in frontend JavaScript — API keys, tokens, database URLs — is readable by anyone who opens the page.
Frontend keys only gate access to a service’s free tier or rate limits; they can’t authenticate users or protect paid APIs.
Put secrets server-side and have the backend call the service, or use the provider’s proper client-auth mechanism.

Why can’t a key in frontend code stay secret?

Because the browser downloads your JavaScript to run it, and anyone can read the network tab or view source to extract every string in it — including keys, tokens, and URLs. Minification and obfuscation only slow a determined reader by minutes. If a key is in code the browser executes, treat it as public. This is why Firebase configs, Stripe publishable keys, and map API keys are designed to be public: they’re meant to be in the client.

What can a public frontend key actually do?

A well-designed public key is restricted by the provider: it can only access public data, or it’s rate-limited per origin, or it can only initiate (not confirm) actions. A mistakenly-exposed secret key is different: it can charge cards, read databases, or spend money. The danger isn’t that a key is in the frontend per se — it’s a secret key being in the frontend, or a public key being used where a real authorization check was needed.

How do I secure the things that actually need protecting?

Anything that costs money or reveals private data must be called from your backend, which holds the secret key and enforces your business rules. The frontend talks to your API; your API talks to the service. Where a provider offers a proper client-auth flow — Firebase Auth, Supabase anon keys with RLS — use that instead of embedding admin credentials. The test: if you can see the key in DevTools, so can an attacker.

# Wrong: secret key shipped to the browser\n# const stripe = Stripe("sk_live_...");  // never do this\n\n# Right: the backend holds the secret, the frontend calls your API\n# POST /api/checkout  ->  backend calls Stripe with the secret key

Where this bites vibecoders
The most common AI-era secret leak: the assistant pastes a service’s secret key or database URL into frontend code because ‘it just works’ in the browser. The developer pushes, the site works, and the key sits in the repo for months — until a scanner or attacker finds it. The habit that prevents it: ask, before generating frontend code, whether the credential is meant to be public (publishable key, anon key) or secret (server-only), and route the latter through your backend.

Where AI coding assistants get this wrong

Embedding secret keys, database URLs, or admin tokens in frontend JavaScript.
Treating ‘it’s in a minified bundle’ as security.
Using a public key where real authorization is needed, letting anyone call the paid API.
Leaving keys in committed code instead of server-side environment variables.

Checklist

Treat every frontend-visible string as public; verify keys are designed for that.
Keep secret keys server-side, in environment variables never shipped to the client.
Route paid or private API calls through your backend.
Scan the repo and deployed bundle for exposed keys (gitleaks, trufflehog).

FAQ

Is it ever OK to have a key in frontend code?

Yes, if the provider explicitly designed it for that: publishable keys, anon keys, and API keys restricted to public data or per-origin rate limits. The line is drawn by what the key can do — if it can spend money or read private data, it doesn’t belong in the browser.

My Firebase config is public — is that a vulnerability?

No, if you’ve configured Firebase rules correctly. The config is meant to be public; the security comes from security rules that restrict what unauthenticated and authenticated users can read and write. The vulnerability appears when rules are left open or admin credentials are embedded.