Explain a Supabase RLS policy

What "leak" means here

• USING (true) — or a tautology like 1=1 — means every row matches. On a table a client role can reach, that reads (or changes) every row. Fix a permissive policy.
• WITH CHECK wider than it should be — on UPDATE, a missing WITH CHECK makes Postgres check the new row against USING, which is fine when USING is strict. When USING has an OR (shared or team rows), a row can be changed into another user's. (An INSERT policy without WITH CHECK doesn't leak: it lets no rows in.) The correct owner-scoped set.
• anon with no auth.uid() scope — signed-out visitors read whatever the predicate allows. Fine for a public catalog; a leak for anything private.
• UPDATE with an open USING — even if WITH CHECK is scoped, an open USING lets any row be targeted. Both matter.

Want the correct policy instead of debugging one? The RLS policy generator writes the whole set from your table.