Environment Variables Exposed in Bolt Client Bundle
Your Bolt.new application is bundling sensitive environment variables into the client-side JavaScript code. Anyone who opens browser DevTools can see your API keys, database connection strings, Stripe secret keys, or other credentials that should never leave the server.
This happens because Bolt's AI may prefix environment variables with VITE_ or NEXT_PUBLIC_, which tells the bundler to include them in the frontend build. While this is correct for public configuration like your site URL, it exposes any secret placed behind those prefixes.
The exposure is often discovered when you receive a massive bill from a third-party API, notice unauthorized data in your database, or when a user reports finding credentials in your page source. By then, the damage may already be done.
Error Messages You Might See
Common Causes
- VITE_ prefix on secret keys — Bolt generated environment variables like VITE_STRIPE_SECRET_KEY or VITE_DATABASE_URL, causing Vite to bundle them into client JavaScript
- Hardcoded secrets in source files — API keys placed directly in .ts or .tsx files rather than using environment variables at all
- No backend proxy for API calls — The app calls third-party APIs (OpenAI, Stripe, Twilio) directly from the browser with embedded keys
- All env vars loaded client-side — A shared config file imports every environment variable and is used in both server and client code
- .env file committed to Git — The .env file containing all secrets was committed to the repository and is visible in the build output
How to Fix It
- Audit your bundle for secrets — Open browser DevTools, go to Sources, and search for 'key', 'secret', 'password', 'token', 'DATABASE' in your JavaScript bundles
- Remove VITE_ prefix from secrets — Rename VITE_STRIPE_SECRET_KEY to STRIPE_SECRET_KEY so it is only available server-side
- Create server-side API routes — Move all third-party API calls to backend routes or Supabase Edge Functions where secrets stay on the server
- Rotate all compromised credentials — If secrets were exposed in production, immediately generate new keys in each provider's dashboard and revoke the old ones
- Separate public and private config — Create two config files: one for public values (VITE_ prefixed) and one for server-only values (no prefix)
- Add .env to .gitignore — Ensure your .env file is listed in .gitignore and remove it from Git history with git filter-branch or BFG Repo Cleaner
Real developers can help you.
You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.
Get HelpFrequently Asked Questions
Which environment variables are safe to expose in the browser?
Only values that are truly public: your Supabase anon key (with proper RLS), site URL, Google Analytics ID, and public feature flags. Never expose database URLs, secret API keys, or payment processor secret keys.
How do I check if my keys have already been exploited?
Check the usage dashboard for each exposed service. Look for API calls you didn't make, unexpected charges, or unfamiliar data in your database. Also check if your .env file appears in any public Git commits.