Supabase row-level security: a practical checklist

With the anon key in your frontend, any table without row-level security is readable and often writable by anyone. Enable it everywhere, then add policies for exactly what each role needs.

alter table public.notes enable row level security;

create policy notes_owner_read on public.notes
  for select to authenticated
  using (owner_id = (select auth.uid()));

• SELECT uses using (...) to filter visible rows.
• INSERT uses with check (...) so users can't create rows for someone else.
• UPDATE needs both: using decides which rows can be changed, with check validates the new values.
• DELETE uses using (...).

A policy that lets users update their own profile also lets them update every column on it — including a role or points column — unless you limit the grant.

revoke update on public.profiles from authenticated;
grant update (display_name, bio) on public.profiles to authenticated;

Actions like “accept a solution and award points” touch several tables and need rules users must not bypass. Put them in a security definer function that checks auth.uid() itself, revoke execute from public, and grant it only to authenticated.

• Using the service-role key in browser code. It bypasses RLS completely.
• Policies that check auth.role() = 'authenticated' only — that allows every signed-in user to read every row.
• Forgetting storage buckets: they need their own policies on storage.objects.
• Testing only as an admin. Test as a second, ordinary user who should be denied.