Fixes · Security holes

Supabase service-role key exposed in the browser

The service-role key skips every Row Level Security rule. Used in browser code, it's handed to every visitor, who can then read, change or delete your whole database.

Most common in apps built with Lovable, Bolt.

What you see

Code that runs in the browser creates a Supabase client with SUPABASE_SERVICE_ROLE_KEY (or a key whose role is service_role).

Why it happens

AI tools reach for the service-role key when a query is blocked by RLS: it makes the error go away by switching security off. In browser code, the key ships to everyone.

How to fix it

Use the anon key in the browser, and fix the RLS policy that blocked the query instead.
Keep the service-role key in server code only: an API route, a server action or an edge function.
Rotate the key in Supabase → Settings → API: it has already shipped.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor, and let it make the change.

The Supabase service-role key is used in code that runs in the browser. Move every use of it to server-side code (an API route or edge function), use the anon key in the browser, and make the RLS policies allow what the app needs. Then tell me to rotate the key in Supabase.

Don't change what the app does.
Never put a secret key or password in the code: read it from an environment variable.
If a step has to be done outside the code, like revoking a key in a provider's dashboard, list it for me at the end instead of skipping it.

How Launchpad helps

The launch check finds the key in browser code and secrets behind a public prefix. Launchpad injects the service-role key only under a server-side name.

Check your app for this, free Join the waitlist