The Supabase RLS Checklist: Lock Down Your Tables Before Launch

Supabase's docs are blunt about this: a table in an exposed schema without RLS can be read and written by any role that has a grant on it. With the anon key sitting in your frontend, that can mean "anyone on the internet."

Tables made in the dashboard Table Editor get RLS on by default. Tables created by SQL, migrations, or your AI assistant may not. Find the stragglers:

-- Tables in public with RLS still off
select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

-- Fix one
alter table public.todos enable row level security;

RLS on with no policies means nobody (except service_role) can touch the table. That's safe, just maybe not what your app wants yet. Steps 3 and 4 fix that.

Two layers protect each table. Grants decide whether a role (anon, authenticated) can reach the table at all. RLS policies decide which rows. Adding policies doesn't remove grants, so if signed-out visitors should never touch a table, take the grant away too:

revoke all on public.reports from anon, authenticated;
grant select, insert, update, delete on public.reports to authenticated;

Handy debugging tip from the docs: a 42501 permission error means a grant is missing, and it fires before any policy runs. Check grants before you loosen a policy.

A single for all policy is easy to get subtly wrong. Separate SELECT, INSERT, UPDATE and DELETE policies are easier to read and test. Always add to authenticated (or to anon) so the policy doesn't quietly apply to everyone.

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

create policy "Delete own todos"
on public.todos for delete
to authenticated
using ((select auth.uid()) = user_id);

Watch for using (true). It means "every row, for everyone this policy applies to." Sometimes that's right (a public blog posts table). Often it's an AI shortcut to make an error go away.

USING filters which existing rows you can see or touch. WITH CHECK validates the row you're writing. Without it on UPDATE, a user could edit their own row and hand it to someone else by changing user_id.

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

create policy "Update own todos"
on public.todos for update
to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);

RLS works on rows, not columns. If a profiles row has is_admin, plan or credits, an "update own profile" policy lets users update those too.

• Move sensitive fields to a separate table that users can only read.
• Or restrict column-level UPDATE grants so only safe columns are writable.
• Change plan, role or credits only from a server or edge function after checking who's asking.

A SECURITY DEFINER function runs with its owner's privileges, and if that owner is postgres (or any role that bypasses RLS), the queries inside it skip your policies. By default, views also run with their creator's permissions. Both are classic ways to accidentally route around your policies.

• Only grant EXECUTE on functions to roles that need them.
• Read every SECURITY DEFINER function and make sure it checks auth.uid() itself.
• For views on Postgres 15+, create them with (security_invoker = true) so the caller's RLS applies.

Files in Supabase Storage are protected by policies on storage.objects, set up separately from your tables. A public bucket means anyone with the URL can download files. For things like invoices or user uploads, use a private bucket with policies that check the owner, and signed URLs.

Policies act like a hidden where clause on every query. Supabase recommends indexing the columns they filter on and wrapping functions as (select auth.uid()) so Postgres can evaluate them once instead of per row.

create index if not exists todos_user_id_idx on public.todos (user_id);

Policies that look right can still leak. The only way to know is to try the things that should fail:

• Signed out: can you read or write anything you shouldn't?
• Signed in as user B: can you read, edit or delete user A's rows?
• Can you insert a row with someone else's user_id?
• Can you update your own plan or is_admin?

Supabase supports database tests with pgTAP via supabase test db, so you can lock these checks in and re-run them after every change.

begin;
select plan(1);
set local role authenticated;
select set_config('request.jwt.claims', '{"sub":"<user-b-uuid>","role":"authenticated"}', true);
select is_empty(
  $$ select * from public.todos where user_id = '<user-a-uuid>' $$,
  'User B cannot see User A todos'
);
select * from finish();
rollback;

The service_role / sb_secret_ key bypasses RLS completely, so none of the above matters if it's in your frontend bundle. If you find it there, follow our calm guide to rotating it. And when an AI assistant suggests the service_role key "to fix a permissions error," fix the policy instead.