Secrets
API keys in frontend code: the rule is simpler than it looks.
Anything in your front-end code is public. Minified, obscured or in an environment variable, it still ships to the browser and anyone can read it. So the rule is simple: publishable keys can live in the front end, secret keys cannot, and a secret key in client code has to move to the server.
Minification is not security.
A common belief is that a key buried in a bundled, minified JavaScript file is hidden. It is not. Anyone can open the network tab or the bundle and read every string in it, including your keys, in under a minute. Front-end code is delivered to the user's machine to run there, which means everything in it is visible to the user. Treat every value in client code as published.
What is safe in the front end
Publishable keys belong in client code and are safe there: a Supabase anon key, a Firebase config, a Stripe publishable key, most analytics and map keys. These identify your project to a service and depend on other controls to protect data. They are built to be seen, so shipping them to the browser is correct, not a leak.
Even so, a publishable key is only as safe as what sits behind it. The anon key needs row-level security; the Firebase config needs security rules. Putting the public key in the front end is fine; leaving the data behind it unprotected is not.
What must stay on the server
Secret keys must never be in front-end code: a Supabase service role key, a Stripe secret key, server API keys for paid services, database passwords, private tokens. These can act on their own, charge money, read all data, send messages, so handing them to the browser hands that power to every visitor. There is no safe way to put a secret key in client code.
Watch the environment-variable trap. Frameworks expose some variables to the browser, usually by a naming prefix, and bundle them into client code at build time. A secret key placed in one of those exposed variables ends up just as public as if you had pasted it into the page. Only truly server-side variables keep a secret secret.
How to move a secret key server-side
The pattern is to put the secret key on a server and have the browser call your server instead of the third-party service directly. Your front end calls an endpoint you control; that endpoint, running on the server where the secret key lives, makes the real call and returns only what the client needs. The key never leaves the server, and you get a place to add auth, rate limiting and validation on the way through.
This is a small piece of backend work, an API route or edge function, and it is the correct fix for any secret currently in your bundle. After moving it, rotate the old key, because it was public for as long as it sat in client code.
Common questions.
- Can I hide an API key in the frontend with obfuscation?
- No. Obfuscation and minification make code harder to read, not impossible, and keys are trivially recoverable from the network tab regardless. If a key must be secret, the only real fix is to keep it on the server and proxy requests through an endpoint you control.
- What about environment variables in my frontend framework?
- Only server-side environment variables are safe for secrets. Variables your framework exposes to the browser, usually by a naming prefix, are bundled into client code and are fully public. Never put a secret in one of those.
- Can you move my keys server-side?
- Yes. As part of an audit or a small piece of feature work, we identify which keys are exposed, build the server-side proxy for the ones that must move, and rotate the compromised keys.
Related services.
Let's build something real.
Tell us about your app or idea. You'll get a clear plan and a fixed quote back within 24 hours.