Skip to content
VibeSafeDaily

LibraryExposed data

A policy uses USING (true) on private rows

Cataloged October 16, 2026 · Lovable · Bolt · Cursor · Replit · v0 · Supabase

Symptom

Row level security is on, and the app still returns every row to any signed-in user, or to nobody at all.

Root cause

Supabase documents that a policy written as `to anon using (true)` grants every unauthenticated visitor read access to every row the role can already reach. `to authenticated using (true)` does the same for every signed-in user. RLS being enabled does not help if the policy adds no restriction. Lovable's Quick scan calls out this pattern as access rules that let everyone through.

Fix prompt

In this project only, find every RLS policy whose USING or WITH CHECK expression is bare true.

For each private table, replace that policy with one that matches the owner. Example shape, which you must adapt to the real owner column:

create policy "users read their own rows"
on public.your_table
for select
to authenticated
using ((select auth.uid()) = user_id);

Leave USING (true) only on tables that are intentionally public, and only for SELECT. Do not grant write with USING (true). Add a test that user B cannot select user A's rows. Do not touch any project other than this one.

Paste this into the coding tool that has your own project open.

2-minute self-check

These steps are for an app you own. Do not run them against someone else's project.

  1. In your own Supabase dashboard, open Authentication policies or run select tablename, policyname, qual from pg_policies where schemaname = 'public' in the SQL editor.
  2. Mark every policy whose expression is just true. Decide whether that table is supposed to be public.
  3. Sign in to your own app as test user B and open a screen that lists private records. You should not see test user A's rows.

Sources

Same symptom