This one is serious. Unlike the anon key, the Supabase service_role key bypasses Row Level Security entirely and has full admin access to your database. If it ended up in Lovable's client code or your repo, anyone who finds it can read and write everything. Rotate it right now, then make sure only the anon key is ever in client code.
Why it's a problem
The service_role key is a master key. It ignores every RLS policy, so no amount of database rules protects you while it is exposed. In a public repo or a browser bundle it means total database compromise: read every row, modify or delete anything. This is the single worst key to leak from a Supabase app.
How to fix it, in order
- 1Rotate the service_role key now. In the Supabase dashboard, regenerate the service_role key immediately. Every hour it stays live is full database exposure.
- 2Remove it from all client code. The service_role key must only ever exist in server code, edge functions, or route handlers. Delete every client-side reference.
- 3Purge it from git history. If it was committed, remove it with filter-repo or BFG and force-push, knowing rotation is what actually protects you.
- 4Move privileged work server-side. Do the operation that needed elevated access in a Supabase edge function or a server route, using the service_role key there and only there.
Why Lovable does this
An assistant sometimes reaches for the service_role key to make a privileged operation work without setting up RLS or a server route, then places it where the client can read it. The operation succeeds, so the exposure is invisible until someone extracts the key.
Stop it happening again
Only the anon key belongs in client code, and only with RLS configured. Keep the service_role key in server-side code read from an environment variable. Scan the app to confirm the service_role key is not anywhere the browser or repo can reach.
The quick fix
- Rotate the service_role key immediately; it grants full database access.
- Remove every client-side reference to it.
- Purge from git history if committed.
- Use the service_role key only in server code or edge functions.
Common questions
How can I tell if Lovable put the service_role key in my client code?
Look in the Supabase client initialization file Lovable generates. If you see a key that is longer than the anon key and labeled service_role or used in an admin client, it must not be there.
What access does the Supabase service_role key actually grant?
Full admin access to your Supabase database, bypassing every RLS policy. Treat it the same as root database credentials; the anon key is not in the same category.
If I rotate the service_role key, will my app break?
Only the operations using that key will fail. Update the key in your server-side environment variables immediately after rotating, and confirm no client code references it.