Supabase service_role or secret key exposed in front-end code

What it means in plain English

The secret key is the master key: it ignores every Row Level Security rule. If it's in your front-end (including any VITE_ or NEXT_PUBLIC_ variable), anyone can open DevTools, copy it and read or delete all your data.

Likely causes

• The AI used the service key to 'fix' an RLS error.
• A secret was put in a VITE_/NEXT_PUBLIC_ variable.
• Key committed to a public GitHub repo.

How to fix it, step by step

1. Search your code for service_role, sb_secret_ and SERVICE_ROLE. Anything in browser code must go.
2. Move privileged work to server code (Edge Function, API route) that reads the secret from a non-prefixed env var.
3. Rotate the key: Supabase Settings → API Keys → create a new secret key → update your server code → then delete the old secret key (or deactivate legacy keys once nothing uses them).
4. Fix the underlying permission problem with proper RLS policies instead.
5. Run Supabase's Security Advisor to catch tables without RLS.

How to check it worked

• Search the built site's JS (DevTools → Sources) for sb_secret or the old key; nothing found.
• App still works using the publishable key + RLS.

Sources

• https://supabase.com/docs/guides/api/api-keys (opens in a new tab)
• https://supabase.com/docs/guides/database/postgres/row-level-security (opens in a new tab)
• https://vite.dev/guide/env-and-mode (opens in a new tab)