How to Fix Supabase API Key Exposure (2026)

The Supabase service_role key gives whoever holds it complete, unrestricted access to your database: every row, every table, no authentication checks, no RLS policies. In our scans of apps built with Bolt, Lovable, and Cursor, finding the service_role key in a client-side JavaScript bundle is the single most common critical finding on Supabase-connected apps.

There's a complication that makes this harder to spot: Supabase gives every project two keys that look almost identical. Both are long JWTs starting with eyJhbGci. Most exposure guides tell you to rotate immediately without explaining which key actually needs rotating.

Two Keys, Two Threat Models

Before doing anything, identify which key you're dealing with.

The Anon Key

The anon key is NEXT_PUBLIC_SUPABASE_ANON_KEY or VITE_SUPABASE_ANON_KEY in most AI-generated apps. Supabase designed this key to live in your frontend. It identifies your project, but it only accesses the data your Row Level Security policies allow. A user hitting your app with the anon key can't read other users' rows as long as RLS is configured correctly.

If only the anon key is exposed: Don't rotate it. Fix or verify your RLS policies instead.

The Service Role Key

This is the dangerous one. It's named SUPABASE_SERVICE_ROLE_KEY and it should never appear in frontend code. When you initialize a Supabase client with this key, the server treats every request as if it came from a trusted admin. RLS does not apply. Every row in every table is readable and writable.

AI coding tools sometimes generate code like this when you ask for a quick admin feature or a data seed script, and the key ends up in a component file that compiles into your JavaScript bundle.

Step 1: Identify Which Key Is Exposed

JSON.parse(atob('YOUR_KEY'.split('.')[1]))

// anon key: not an emergency
{ "role": "anon", "iss": "supabase", "iat": 1710000000 }

// service_role key: rotate immediately
{ "role": "service_role", "iss": "supabase", "iat": 1710000000 }

# Find service_role key usage in source files
grep -r "service_role" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" --include="*.vue" .

# Find environment variables with public prefixes that shouldn't be public
grep -r "NEXT_PUBLIC_SUPABASE_SERVICE_ROLE\|VITE_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 Service_Role Key

If your audit found the service_role key exposed, rotate it before anything else.

Step 3: Remove from Git History (if committed)

Rotation stops the current key from working. But if the key was ever in a git commit, everyone who cloned the repo before the scrub may still have a copy.

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

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

# If you committed the key directly in a config file, use path-regex
git filter-repo --paths-glob "**/*supabase*key*" --invert-paths

After scrubbing, force-push to all remotes and ask collaborators to re-clone. Add the files to .gitignore:

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

Step 4: Fix Client Code to Use Anon Key with RLS

Rotating the key stops the immediate problem. Fixing the code prevents it from happening again.

The Pattern AI Tools Generate

Tools like Bolt and Lovable sometimes generate an "admin" Supabase client in a component when you ask for operations that need admin access:

// Wrong: service_role in a React component or Vue page
import { createClient } from '@supabase/supabase-js';

const supabaseAdmin = createClient(
  process.env.VITE_SUPABASE_URL!,
  process.env.VITE_SUPABASE_SERVICE_ROLE_KEY! // this ends up in the bundle
);

The fix has two parts: use the anon key in the browser, and write RLS policies so the anon key can only access what it should.

// Right: anon key in client-side code, controlled by RLS
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL!,
  import.meta.env.VITE_SUPABASE_ANON_KEY! // safe, governed by RLS policies
);

Use the Service_Role Key Only in Server-Side Code

For operations that actually need admin access (seed scripts, webhook handlers, admin APIs), put the service_role key in a server-side function:

// server/api/admin-action.post.ts (Nuxt server route)
// api/admin-action.ts (Vercel Route Handler)
// supabase/functions/admin-action/index.ts (Supabase Edge Function)

import { createClient } from '@supabase/supabase-js';

const supabaseAdmin = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY! // no VITE_ or NEXT_PUBLIC_ prefix
);

// This code never runs in a browser

If you're on Next.js, store it in SUPABASE_SERVICE_ROLE_KEY (no NEXT_PUBLIC_ prefix). Access it only in Route Handlers or Server Actions. If you're on Vite (Lovable, most SvelteKit apps), VITE_-prefixed variables go into the browser bundle by design. Store the service_role key without the prefix in a separate .env.server file or pass it through a backend API.

Step 5: Enable RLS on Every Table

Once your client code is using the anon key, RLS is what keeps the anon key safe. Without it, the anon key gives full database access to every visitor.

Open your Supabase dashboard, go to Database > Tables, click each table, and check Row Level Security. Enable it if it's off. Then add policies that match your app's access model.

Minimum policy for user data (users can only read their own rows):

-- Enable RLS first
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

-- Users can read their own profile
CREATE POLICY "profiles_select_own"
  ON profiles FOR SELECT
  USING (auth.uid() = user_id);

-- Users can update their own profile
CREATE POLICY "profiles_update_own"
  ON profiles FOR UPDATE
  USING (auth.uid() = user_id);

For public data (anyone can read, only authenticated users can write):

CREATE POLICY "posts_public_read"
  ON posts FOR SELECT
  USING (true);

CREATE POLICY "posts_auth_insert"
  ON posts FOR INSERT
  WITH CHECK (auth.uid() IS NOT NULL);

Step 6: Prevent Future Leaks

Add Gitleaks as a pre-commit hook:

brew install gitleaks  # or: go install github.com/zricethezav/gitleaks/v8@latest

# Test your repo now
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

Gitleaks has built-in detection patterns for Supabase service_role JWTs.

Environment variable checklist: