Never Put Secrets in the Frontend
What it is
The single most common security mistake in AI-built apps: a secret — an API key, a database password, a payment or email provider token — ends up in code that runs in the user's browser, where anyone can read it by opening developer tools. AI does this constantly because the quickest way to make a feature work is to put the key right where it's used.
Why it works
Anything shipped to the browser is fully visible to whoever loads the page — there is no hiding a key in frontend code, only obscuring it briefly. A leaked key lets a stranger run up your bill, send email as you, or read and write your data. The fix is architectural: secrets live on the server (in environment variables) and the browser calls your server, which uses the key on its behalf and never reveals it.
When to use it
Apply this the instant your app talks to any paid or privileged service — an AI API, a database, email, payments, storage. That's almost every real app, so treat it as a default rule.
When not to use it
The only keys safe to expose are ones explicitly designed to be public (some analytics or map keys, or 'publishable' keys that are restricted by design). Even then, confirm the provider intends them to be public before shipping.
Prompt
Audit this app for any secret — API keys, tokens, database credentials, provider secrets — that is present in frontend/client code or the browser bundle. For each one, move it to a server-side environment variable and route the request through a backend endpoint so the secret never reaches the browser. Show me what you changed and confirm nothing sensitive is left client-side.Example
An app calls an AI provider directly from the browser with the API key hard-coded in the JavaScript. Within days a scraper finds the key and racks up thousands in usage. The fix: the browser calls a small backend route, the backend holds the key in an environment variable, and the key never leaves the server.
Advanced version
Beyond moving keys server-side, add a check to your build or review that fails if anything key-shaped appears in the client bundle, rotate any key that was ever exposed (obscuring is not rotating), and scope each key to the minimum permissions it needs so a leak is contained.
Common mistakes
- Letting the AI 'just make it work' by calling a paid API straight from the browser with the key inline.
- Thinking a key is safe because it's in a variable or minified — the browser still exposes it fully.
- Not rotating a key after it was committed to code or shipped to the client, leaving the leak live.