How to Fix Lovable API Key Exposure (2026)

A Lovable app with an exposed OpenAI key can drain your credits in hours. In our scan of Lovable-generated deployments, exposed API keys and Supabase service_role misuse were the two most common critical findings. The root cause is almost always one of two patterns: a variable named VITE_OPENAI_API_KEY that Vite bakes into the client JavaScript bundle at build time, or Lovable's AI generating a Supabase client in a React component using the service_role key.

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 Lovable project directory
grep -r "VITE_" . --include="*.env*" --include="*.ts" --include="*.tsx" --include="*.js"

# In your Lovable project files
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, they are visible in every past commit, even if you deleted the file later.

# 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 for VITE_ Secrets

Rotating fixes the immediate risk. Fixing the root cause stops it from recurring.

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):

// In a Lovable-generated React component - leaks key to the browser
const response = await fetch("https://api.openai.com/v1/chat/completions", {
  headers: {
    Authorization: `Bearer ${import.meta.env.VITE_OPENAI_API_KEY}`, // visible to all
  },
});

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

// supabase/functions/chat/index.ts - server-side only
import { serve } from "https://deno.land/std@0.177.0/http/server.ts";

serve(async (req) => {
  const { message } = await req.json();
  const response = await fetch("https://api.openai.com/v1/chat/completions", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${Deno.env.get("OPENAI_API_KEY")}`, // never reaches browser
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      model: "gpt-4o",
      messages: [{ role: "user", content: message }],
    }),
  });
  const data = await response.json();
  return new Response(JSON.stringify({ reply: data.choices[0].message.content }), {
    headers: { "Content-Type": "application/json" },
  });
});

Your React component calls your Supabase Edge Function URL. The Edge Function calls OpenAI. The key never reaches the browser.

Variable Storage in Supabase

Store secrets in Supabase under Project Settings > Edge Functions > Secrets. Reference them in Edge Functions only:

Then access it in your Edge Function as Deno.env.get("OPENAI_API_KEY"). Supabase injects it 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.

Lovable's AI occasionally generates a Supabase client in a React component or hook using 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 a React component):

// In a Lovable-generated React hook - full database access for any visitor
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_SERVICE_ROLE_KEY // never do this
);

Right (anon key in React, service_role only in Edge Functions):

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

// supabase/functions/admin-task/index.ts - service_role only here
import { createClient } from "https://esm.sh/@supabase/supabase-js@2";
const adminClient = createClient(
  Deno.env.get("SUPABASE_URL")!,
  Deno.env.get("SUPABASE_SERVICE_ROLE_KEY")! // server-side only
);

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

Step 6: Prevent Future Leaks

Pre-commit Hook with Gitleaks

Gitleaks scans your staged files 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

Where Secrets Go in a Lovable App