The service role key is in the browser bundle

Symptom

Data API calls from the site ignore every row policy. Searching the shipped JavaScript turns up a secret or service role key.

Root cause

Supabase's securing-your-data guide says the publishable key and the older anon key are safe to expose only when RLS and least-privilege grants are in place. The secret key and the service role key bypass RLS and are never safe in the browser. Lovable's security best practices say secrets stored in frontend code are visible to users and should be considered compromised, and that the service role bypasses RLS so server code using it must check permissions itself.

In this repository only, search client components, Vite env files, and NEXT_PUBLIC_ variables for service_role, sb_secret, SUPABASE_SERVICE_ROLE_KEY, and the secret key value.

1. Remove every client use of the secret or service role key.
2. Create the browser client with the publishable (or anon) key only.
3. Move privileged work into a server route or Edge Function that reads the secret from server env, and authorize the caller before using an admin client.
4. Rotate the leaked key in the Supabase dashboard after the code no longer references the old value.

Do not print the key in logs or in chat.

Paste this into the coding tool that has your own project open.

2-minute self-check

These steps are for an app you own. Do not run them against someone else's project.

1. Open a production build of your own site. In DevTools, search the loaded scripts for service_role and sb_secret. Those strings should not appear.
2. Search your own repo for SUPABASE_SERVICE_ROLE_KEY and confirm it is referenced only from server files.
3. If you find the secret in a shipped bundle, rotate it in your own Supabase API settings after the new deploy.

Sources

• Supabase: Securing your data
• Lovable: Security best practices