The Supabase RLS checklist

Is row-level security on by default in Supabase?

It depends how the table was created. Supabase's docs state that RLS is enabled by default on tables created with the Table Editor in the dashboard — but if you create a table with raw SQL, you have to remember to enable RLS yourself. That difference is where a lot of accidental exposure comes from, because AI builders often create schema via SQL.

Worth auditing every table, not just the recent ones: select relname, relrowsecurity from pg_class where relnamespace = 'public'::regnamespace; lists every table in your public schema with whether RLS is on.

Is it safe to expose the Supabase anon key?

Yes. Supabase documents the publishable (anon) key as safe to expose in a web page, mobile or desktop app, CI, or source code. What protects your data is Postgres row-level security on the anon and authenticated roles — not the secrecy of that key. Supabase is explicit that RLS must always be enabled on any table in an exposed schema.

The corollary matters as much: Supabase notes that publishable keys are not intended to protect against code analysis or browser inspection, because retrieving a key from a public component is always possible. If your security depends on nobody finding the key, you don't have security — you have obscurity.

Why does my app return an empty list after I enabled RLS?

Because enabling RLS without policies denies everything. Supabase's docs put it plainly: no data will be accessible via the API using a publishable key until you create policies. This is the safe failure mode — fix it by adding the policy you meant to add, never by turning RLS back off.

Do I need a separate policy for every operation?

Effectively yes, and they use different clauses. SELECT and DELETE policies use using; INSERT policies use with check; UPDATE uses both — using to decide which existing rows can be changed and with check to validate the new values. Supabase also notes that an UPDATE policy requires a SELECT policy to work.

The usual owner check is a comparison against auth.uid(), which returns the ID of the user making the request. A minimal per-user read policy is using (auth.uid() = user_id) — and the equivalent needs to exist for insert, update and delete before the table is actually scoped.

Does the service role key respect my policies?

No. It uses the Postgres BYPASSRLS attribute, which skips any and all row-level security policies you attach. Supabase's guidance is to never expose secret keys publicly — not in web pages, public documents, source code, or bundled into mobile, desktop or CLI apps, and never in a browser even on localhost.

Legitimate uses are server-side and developer-controlled: your own backend, edge functions, and admin tooling that does its own authorization checks before acting.

Do views respect RLS?

Not by default. Supabase documents that views bypass RLS because they are usually created with the postgres user. On Postgres 15 and later you can set security_invoker = true on the view so it obeys the policies of the underlying tables instead of the creator's privileges.

This is a genuinely easy one to miss, because the table it reads from is correctly protected. Inventory your views alongside your tables.

How do I test that RLS actually works?

Test as two real users, through your app's public key — never with the secret key, which bypasses everything and will make a broken setup look fine. Create a record as user A, then sign in as user B and try to read, update and delete it by id.

Do it for each of the four operations, not just reads, and repeat it for every table that holds customer data. Supabase's docs point to a community approach using pgTAP if you want these as automated database tests rather than a manual pass.