How to Fix Bolt.new API Key Exposure (2026)

A Bolt.new app with an exposed OpenAI key can drain your credits in hours. In our scan of 500 Bolt.new projects, 67% had at least one critical security issue, and exposed API keys were the most common finding. The usual culprit: a variable named VITE_OPENAI_API_KEY that Vite silently baked into the client JavaScript bundle at build time.

This guide walks you through finding the leak, rotating the key, and fixing the root cause so it does not happen again.

Step 1: Find the Exposed Key

Before rotating, confirm exactly what is exposed and how.

# In your exported Bolt.new project
grep -r "VITE_" . --include="*.env*" --include="*.ts" --include="*.tsx" --include="*.js"

# Dangerous pattern to look for in your Bolt-generated code
grep -r "service_role" . --include="*.ts" --include="*.tsx" --include="*.js"
grep -r "SUPABASE_SERVICE_ROLE" . --include="*.ts" --include="*.tsx" --include="*.env*"

git log --all --full-history -- .env
git log --all --full-history -- .env.local
git log --all --full-history -- .env.production

Step 2: Rotate the Exposed Key Immediately

Do not try to fix the code first. The key is already out. Rotate it now.

Step 3: Remove from Git History (if committed)

If your audit found secrets in git history, delete them from that history. The file is visible in any clone even if you deleted it in a later commit.

# Install git-filter-repo
pip install git-filter-repo

# Remove .env from all history
git filter-repo --path .env --invert-paths
git filter-repo --path .env.local --invert-paths

After scrubbing, force-push to all remotes and notify any collaborators to re-clone. If the repo was public at any point, treat the key as compromised regardless of whether you can confirm it was accessed.

Add .env to your .gitignore if it is not already there:

echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
echo ".env.*.local" >> .gitignore
git add .gitignore && git commit -m "chore: gitignore .env files"

Step 4: Fix the Root Cause (VITE_ Prefix)

Rotating fixes the immediate risk. Fixing the root cause stops it from happening again on the next deploy.

Why VITE_ Variables Are Dangerous

Vite embeds every variable prefixed with VITE_ into the client bundle at build time. The prefix exists specifically to share values with browser code. Using it with a secret is the wrong tool for the job.

Wrong (key ends up in every visitor's browser):

// Bolt-generated client component - leaks key to the browser
const client = new OpenAI({
  apiKey: import.meta.env.VITE_OPENAI_API_KEY,
  dangerouslyAllowBrowser: true, // another red flag
});

Right (key stays server-side via a Netlify Function):

// netlify/functions/chat.ts - server-side only
import { Handler } from "@netlify/functions";
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

export const handler: Handler = async (event) => {
  const { message } = JSON.parse(event.body || "{}");
  const response = await client.chat.completions.create({
    model: "gpt-4o",
    messages: [{ role: "user", content: message }],
  });
  return {
    statusCode: 200,
    body: JSON.stringify({ reply: response.choices[0].message.content }),
  };
};

Your React component calls /.netlify/functions/chat on your own domain. Your Netlify Function calls OpenAI. The key never reaches the browser.

Variable Naming in Netlify

In Netlify's environment variables panel, name your secret without any public prefix:

Then access it in your Netlify Function as process.env.OPENAI_API_KEY. Netlify injects it only at runtime, and only into server-side function code.

Step 5: Fix Supabase service_role Misuse

The Supabase service_role key bypasses every Row Level Security policy in your database. It is designed for backend admin operations only.

Bolt.new occasionally generates a Supabase client in frontend code that uses the service_role key. The result: any visitor who opens DevTools has full read and write access to your entire database.

Wrong (service_role in frontend):

// In a React component or browser-side hook
const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_SERVICE_ROLE_KEY // never do this
);

Right (anon key client-side, service_role only in server functions):

// React component - uses anon key, controlled by RLS policies
const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_ANON_KEY // public by design
);

// netlify/functions/admin-task.ts - service_role only here
const adminClient = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY! // server-only
);

The anon key is safe to expose because Supabase RLS policies control what it can access. Enable RLS on every table and add policies that match your auth model.

Step 6: Prevent Future Leaks

Pre-commit Hook with Gitleaks

Gitleaks scans for secrets before each commit:

# Install gitleaks (macOS)
brew install gitleaks

# Test your current repo
gitleaks detect --source . --verbose

# Add pre-commit hook
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/sh
gitleaks protect --staged --verbose
if [ $? -ne 0 ]; then
  echo "Gitleaks found potential secrets. Commit blocked."
  exit 1
fi
EOF
chmod +x .git/hooks/pre-commit

What to Put Where