Your .env File Is Not the Secret. Your Built JavaScript Is.

If you built an app with Lovable or Bolt and you put an API key in a file called .env, here is the uncomfortable truth: that file is not what protects you. What ended up in the built JavaScript is.

How the leak works

When you build a Vite app — and Lovable and Bolt apps are Vite apps — any variable that starts with VITE_ gets baked straight into the JavaScript bundle your site ships to every visitor. That is by design. Vite's own documentation says these variables "will be exposed in client-side source code after Vite bundling" and warns they "should not contain sensitive information such as API keys."

So when your app calls an AI API or a payment API straight from the frontend with a VITE_OPENAI_API_KEY, the key travels with the page. Anyone can open DevTools, search the loaded scripts for sk- or sk_live, and copy it. Then they can run up your bill on your account.

This is not a rare edge case. It is the fastest way to make a feature work — ask for "summarise this with OpenAI" and you get a working screen in minutes — and the fastest way to leak the key that powers it. A guide published today, October 24, 2026, walks through exactly how keys leak from Lovable and Bolt apps this way, and the fix.

The three-step fix

1. Move the call to the server. Create a server-side function — a Supabase Edge Function, a Netlify function, or a Vercel function — and make the API call there, not in the browser.

2. Store the key as a server secret. No VITE_ prefix. The key lives in your server's secrets, and the frontend calls your function instead of the provider. Check inside the function that the caller is logged in, so strangers can't use it as a free proxy.

3. Rotate the old key. This is the step people skip, and it matters most. The old key is in every copy of your old bundle, including CDN and browser caches. Rotating is the only way to kill it.

Here is a prompt that works in Lovable, Bolt, or Cursor, adapted from today's guide:

Move every call that uses a secret API key out of the frontend into a Supabase Edge Function that reads the key from Supabase secrets. Remove the VITE_ variable for it and call the function instead. Only allow logged-in users to call it. Don't print any keys in your reply.

Check what your live site actually ships

Your .env file isn't what matters. What matters is what ended up in the built JavaScript. Two quick ways to check:

• Open your live site, open DevTools, search all files for sk-, sk_live, service_role, and sb_secret_. You should find nothing.
• Or run your URL through a free checker. Ours is VibeCheck, the free health check for Lovable, Bolt, v0, and Replit apps (https://futureassistingco.netlify.app) — it scans for leaked keys, open databases, and broken auth, and it never asks for your passwords.

One more thing: the October 30 change won't save old apps

Supabase is changing its defaults on October 30, 2026: new tables won't be exposed to the Data API until you grant access explicitly. That helps future apps. It does not fix yours — tables your app already has keep their current grants, so anything already leaking stays leaking until you fix its grants and Row Level Security policies. If your app sends email, our sister tool InboxCheck (https://inboxcheckandfutureassistingco.netlify.app) runs the same kind of plain-words check on your domain's email setup.

The rule to remember: if the browser can see it, everyone can see it. Keys belong on the server. Check your built app, not just your source code — because the built app is what the world actually gets.

Sources: "Are VITE_ environment variables secret? No, and here's how keys leak from Lovable and Bolt apps" (dev.to, October 24, 2026); "Your AI-Built MVP Might Be Leaking Secrets: A Pre-Launch Checklist" (Medium, October 2026); Supabase breaking change, "Tables not exposed to Data and GraphQL API automatically" (April 28, 2026).