Client-Side Secrets

Client-side secrets are API keys, database credentials, and other sensitive values embedded in frontend JavaScript during rapid AI generation, visible to anyone who opens browser developer tools. They exist because the fastest way to make something work is to put the key where the code runs. AI tools optimize for working demos, not secure architecture. The result ships straight to production with liabilities sitting in plain sight.

Every vibe-coded product we audit shows the same pattern. The builder prompts for Stripe integration. The model drops the publishable key and the secret key in the same file because that makes the demo work instantly. No one reviews the architecture. The product ships. The secret waits for the first curious user.

Client-side secrets are not the same as environment variables done correctly. They are not a minor configuration issue. Founders often dismiss them as theoretical risks until the first breach hits their specific product. Then the theory becomes expensive reality.

The common mistake is assuming the AI would not do something stupid. The models do exactly what the fastest path requires. If putting the key in the browser bundle makes the prompt succeed the model does it. Judgment is not part of the training objective.

Concrete example. A payment tool built with Bolt in late 2025 left its Supabase service role key in the client bundle. A user opened DevTools on day 12, found the key, and dumped every row in the database. The founder learned about it from an angry customer instead of their own monitoring. The fix was moving all secrets to server-side environment variables and adding a content security policy that blocked unexpected domains. That single change took 40 minutes and removed the largest immediate liability.

We saw another case where an AI-generated contact form exposed an OpenAI key client-side. Every form submission logged the key in browser history. The key had generous rate limits and the founder received a $1,200 surprise bill before they rotated it. These stories repeat because the pattern is baked into how the tools generate code.

Fix client-side secrets before your first traffic spike or funding round. They are the fastest way to turn a weekend project into a liability. Do not fix them if you have not yet validated that the product should exist. The tradeoff is minor inconvenience for major protection. Moving keys server-side requires a backend route but prevents instant exploitation. That trade is always worth it.

The first place we look in any AI codebase is the client JavaScript. If we find a secret string the entire engagement starts with moving it. Every single time it improves the product immediately.

Add a content security policy header while you are at it. Audit every environment variable. Confirm nothing leaks to the client layer. These steps feel tedious until the moment they save you.

Client-side secrets turn your users into potential attackers without them even trying. Remove them before someone does.

The demo works because the key is there. The business works only after the key is gone. Choose accordingly.