Home / RLS / Fix a permissive USING (true) policy

Supabase RLS · Fix

USING (true) is a security hole — how to fix it

01 Why USING (true) leaks

An RLS policy's USING clause is the filter for which rows a caller may see. USING (true) evaluates true for every row and every caller — so anyone with your anon key can read the whole table. It's the second most common Supabase leak, right after RLS being off, and it usually gets copy-pasted in from a tutorial that just wanted the demo to work.

02 Find every permissive policy

audit.sql

select schemaname, tablename, policyname, cmd, qual
from pg_policies
where schemaname = 'public'
  and qual = 'true';      -- USING (true)

Also check with_check = 'true' for permissive writes. Anything that comes back is a table any user can read (or write).

03 Replace it with a scoped policy

migration.sql

drop policy "public read" on notes;

create policy "owner reads own notes" on notes for select
  using (user_id = (select auth.uid()));

04 If you actually want public read

Sometimes public read is the point (a blog, a public profile). Do it on purpose and scope the columns — don't expose the whole row. Restrict to a published flag and select only safe columns:

migration.sql

create policy "anyone reads published posts" on posts for select
  using (is_published = true);

That still isn't USING (true) — it's a deliberate rule. Keep private columns out of any table that has a public policy.

FAQ