Is it safe to expose the Supabase anon key? Yes, it's built to be public. The key you must never ship is the other one.

Supabase's docs say the publishable key (the newer anon key) is "safe to expose online" and add: "Anyone can read it, so it only reaches what Row Level Security allows." So an anon key in your Lovable or Bolt front end is normal. RLS protects your data, not hiding that key.

The one that must stay on the server is the service_role key, now called a secret key. It bypasses RLS: whoever has it can read and change every row. Supabase: "Never put one in a browser, a shipped application, or source control."

How to tell which key you shipped • An old-style key is a JWT. Decode its middle part: "role":"anon" is the public one, "role":"service_role" is the secret one. • New keys say it in the name: sb_publishable_ is public, sb_secret_ is not. • Check every VITE_, NEXT_PUBLIC_ or REACT_APP_ variable. Vite's docs: VITE_ variables "will be exposed in client-side source code after Vite bundling." • Need admin access? Use an Edge Function: SUPABASE_SERVICE_ROLE_KEY is already there by default.

Found a secret key in your front end? Supabase says to rotate it as soon as you fix the cause of the leak. Deleting it from the code isn't enough: your git history still has it.

The audit tool I built for Lovable, Bolt, Base44 and Replit apps flags both as critical: a service_role or sb_secret_ key in the code, and a secret in a browser-exposed variable. It leaves the anon and publishable keys alone on purpose: flagging them would be a false alarm.

Is the anon key the only Supabase key in your front end, or have you never checked?