Exposed Supabase service_role key: what to do now

If your service_role JWT is in the browser bundle, treat the database as compromised. Rotation and cleanup steps.

The Supabase service_role key bypasses RLS entirely. It belongs only on a trusted server (Edge Functions, a backend you control). If it appears in your JS bundle, assume an attacker already has it.

Do this immediately

1. Rotate. Supabase → Project Settings → API → reset the JWT secret / rotate service_role (and update any legitimate server that used the old key).
2. Remove it from client code and redeploy. Search the repo for service_role and SUPABASE_SERVICE.
3. Audit data. Check for unexpected rows, new users, or modified storage objects since the key was public.
4. Enable RLS on every table if it is not already on — rotation alone is not enough if policies are missing.

Escape.tech's vibe-coded apps study found hundreds of exposed secrets across public apps, with misconfigured Supabase permissions as a primary cause (State of Security of Vibe Coded Apps).

CRITICAL: remove every use of the Supabase service_role key from client/frontend code. Use the anon key in the browser. Move privileged operations into a Supabase Edge Function that reads the service role from server secrets. Enable RLS on all tables with auth.uid() policies.

Related: Enable RLS · Is my Lovable app secure?

More guides

• Is my Lovable app secure?
• How to enable Supabase Row Level Security (RLS)
• Lovable security checklist
• Bolt.new security checklist