How to check Supabase Row Level Security (RLS)

select tablename, rowsecurity as rls_enabled
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

Every row with false needs fixing. Turning RLS on with no policy blocks all access through the API, which is safe but may break your app until you add policies:

alter table public.orders enable row level security;

The Security Advisor (Advisors → Security Advisor) shows the same problem as “RLS disabled in public”, along with other warnings worth reading.

select tablename, policyname, cmd, roles, qual as using_expr, with_check
from pg_policies
where schemaname = 'public'
order by tablename;

Look for these patterns:

• using_expr is true and roles includes anon or public: anyone can read the table. Fine for a list of blog posts, not for users or orders.
• roles is authenticated and the expression doesn’t mention auth.uid(): any signed-in user can read every row. With open sign-ups, that is anyone.
• cmd is INSERT or UPDATE and with_check is empty: users can write rows with someone else’s user_id.
• An ownership check on a column the user can change, like user_id in an update without with check.

For a table where each row belongs to one user:

create policy "Read own orders" on public.orders
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "Create own orders" on public.orders
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

Writing (select auth.uid()) instead of auth.uid() lets Postgres evaluate it once per query instead of once per row, which matters on large tables. Add an index on user_id for the same reason.

The SQL editor runs as an admin and ignores RLS, so it can’t tell you what a visitor sees. Use the API with only your public key, from a terminal:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/orders?select=*&limit=1" \
  -H "apikey: YOUR_ANON_OR_PUBLISHABLE_KEY"

An empty list [] means a visitor with no account sees nothing. Any row in the answer means anyone can read that table. Test each table that holds personal data, and test again signed in as a second user to check they can’t see the first user’s rows.

• The service_role (or secret) key ignores RLS. It must never be in frontend code. If it was, rotate it.
• Views run with the permissions of their owner by default, so a view over a protected table can expose it. Create views with with (security_invoker = true), or keep them out of the public schema.
• Functions marked security definer in the public schema can be called through the API and also skip RLS. Check who can execute them.
• Storage has its own policies, on storage.objects, and buckets marked public skip them for downloads.

Policies drift as your app changes: a new table added by your AI tool can arrive without RLS. Our code scan flags migrations that create tables without RLS on every pull request, and our backend checks test which tables a visitor with no account can read on your live site, counting rows without downloading them. Both are included in the free plan, with the backend check once a month (weekly on Pro), and backend checks run only after you prove you own the site.