Supabase RLS disabled warning

Why the warning exists

The Supabase anon key is in your frontend on purpose. It identifies the project. It is not a secret. With that key, anyone can call your PostgREST API. Row Level Security is what decides which rows that call can see.

If RLS is off on a table in the exposed schema (usually public), the anon key can read and, depending on grants, write every row. The dashboard warning is telling you that. It is not a style hint.

Turn it on, then add policies

Enabling RLS with no policies denies access. That is the safe default, and it will break a working app until you add policies. Do it in a branch or when you can test signup and the main screen.

For a table of rows a user owns, the usual shape is a user_id column defaulting to auth.uid(), plus select, insert, update, and delete policies whose expression is auth.uid() = user_id. Use separate policies per command. A single “all” policy is harder to read later.

Tables that are meant to be public (a blog, a pricing table) still want RLS on, with a select policy of using (true) and no insert policy for the anon role. “Public read” and “RLS disabled” are not the same thing.

service_role is not the fix

The service_role key bypasses RLS. It belongs on a server you control, never in Lovable, Bolt, or other frontend code, and never in a NEXT_PUBLIC variable. If a launch check finds service_role in the page, rotate it in Settings → API before you do anything else. The old key keeps working until you rotate it.

After policies exist, test with the anon key while logged out, and with a normal user session. The SQL editor runs as a privileged role, so a query that works there does not prove the browser is allowed.