Lovable and the Supabase service_role key: how it leaks

Lovable wires your app to Supabase and writes the queries for you. Most of the time it uses the key that belongs in a browser. The failure mode worth checking for is what happens when a query is refused: Row Level Security says no, the build is blocked, and there is a key sitting in the same settings page that makes every refusal go away.

Check your published app

echo "THE_KEY" | cut -d. -f2 | base64 -d 2>/dev/null | grep -o '"role":"[^"]*"'

# "role":"anon"          → expected, this one belongs in the browser
# "role":"service_role"  → rotate it now

If you find it

1. 01Rotate first: Supabase dashboard → Settings → API → reset the service_role key. Do this before touching the code, because the old key keeps working until you do.
2. 02Update the places that legitimately used it — Edge Functions, server environment variables — then redeploy and confirm they still work.
3. 03Fix the code path that leaked it, using the prompt below.
4. 04Check Logs → API for bulk SELECT queries against user tables from an IP that is not yours, over the period the key was public.
5. 05Check Auth → Users for accounts you did not create, and your tables for rows or deletions you cannot account for.

Stopping it happening again

The underlying cause is almost never malice or a bug in the builder — it is that an RLS error is an obstacle and the service_role key is the shortest way past it. The durable fix is to make the legitimate path work: write policies that permit what your app actually does, and move any operation that genuinely needs elevated access into an Edge Function where the key never reaches a browser.

Audit how this project uses Supabase keys.

1. Find every Supabase key in the project and decode each long eyJ token,
   reporting its role claim. Include environment variables and any
   sb_secret_ / sb_publishable_ keys.
2. For each, tell me whether the code holding it runs in the browser or on
   the server.
3. If any service_role or sb_secret_ key is reachable from client code, say
   so first, then rewrite those calls to use the anon key and work through
   Row Level Security instead.
4. If an operation genuinely needs to bypass RLS, move that operation into
   a Supabase Edge Function and keep the key server-side — do not move the
   key toward the client.
5. Confirm no client-exposed variable name (VITE_, NEXT_PUBLIC_,
   REACT_APP_) holds a secret key.

Do NOT fix a row-level security error by switching to the service_role key,
and do not disable RLS. If a query cannot work without one of those, tell
me which query and why.