Supabase service_role key exposed: what to do right now

This is the one Supabase mistake that is a genuine emergency. The service_role key bypasses Row Level Security entirely and has full admin access, so if it reached the browser or a public repo, anyone who found it can read, change, or delete everything in your database. Move quickly, in this order.

1. Rotate the key now

Do this first, before anything else. In your Supabase dashboard under Project Settings → API, generate a new JWT secret — this invalidates both the anon key and the service_role key and generates new ones. Update every environment variable that held the old value and redeploy. Every minute the exposed key is still valid is a minute someone can use it. Do not start by cleaning up the code; start by making the leaked value useless.

2. Get it out of the client and the repo

The service_role key must never be in client code or committed to a repository. Remove it from any client component or browser-reachable file. If it was committed, deleting the file in a new commit is not enough — it stays in git history. Purge it with git-filter-repo:

# Install git-filter-repo first: pip install git-filter-repo or brew install git-filter-repo

# Option A: remove the .env file from all history
git filter-repo --path .env --invert-paths

# Option B: redact just the key value wherever it appears
printf 's/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.YOUR_ACTUAL_KEY/REDACTED/g' > replacements.txt
git filter-repo --replace-text replacements.txt

# After rewriting, force-push and tell collaborators to re-clone
git push origin --force --all

The new key belongs only in a server-side environment variable with noNEXT_PUBLIC_ prefix:

# .env.local (gitignored)
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI...

# In server code only — never in a client component
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!, // no NEXT_PUBLIC_ prefix = server only
);

3. Check for damage

Assume the key was found and used. In the Supabase dashboard, check your table data for unexpected inserts, updates, or deletes. Look at your project’s logs under Logs → API Logs and filter for your service_role key (it appears in the Authorization header as a Bearer token). If you see requests you do not recognize, treat this as a confirmed breach. If you hold sensitive user data, consider your notification obligations — GDPR, CCPA, and SOC 2 all have breach reporting requirements.

4. Fix the root cause: configure RLS

The service_role key usually ends up on the client because someone used it to skip Row Level Security. The real fix is to set RLS up so the client only ever needs the anon key. Enable RLS on every table with owner-scoped policies, and confirm an anonymous read returns nothing:

-- Enable RLS on every table
alter table public.your_table enable row level security;

-- Allow users to read only their own rows
create policy "read own rows"
on public.your_table for select
using ( auth.uid() = user_id );

-- Verify: an anon request should return nothing
-- Test with your public anon key (not service_role)
const anonClient = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY);
const { data } = await anonClient.from('your_table').select('*');
console.log(data); // should be [] for an unauthenticated request

Full policy examples in the Supabase RLS policy examples guide, and the complete launch checklist in the Supabase RLS checklist.

Frequently asked questions

Confirm it's really gone

After rotating and cleaning up, verify the service_role key is not still sitting in a bundle or your history somewhere. A scan reads what your deployed app serves and the repo the way an attacker's bot does, and flags a service_role key that reached the client. Run a free scan to confirm.