The RLS Role Confusion That Leaks Every User’s Data

When AI builders like Lovable or Cursor generate Supabase Row Level Security (RLS) policies, they commonly write the following: ```sql -- What AI often generates (WRONG) CREATE POLICY "Users can view data" ON public.user_data FOR SELECT USING (auth.role() = 'authenticated'); ``` This policy checks only whether someone is logged in — not whether they own the row. The result: every authenticated user can read every row in the table. The correct policy checks ownership: ```sql -- Correct CREATE POLICY "Users can view their own data" ON public.user_data FOR SELECT USING ((select auth.uid()) = user_id); ``` The difference between `auth.role()` and `auth.uid()` is one function call. `auth.role()` returns `'authenticated'` for any logged-in user. `auth.uid()` returns the UUID of the specific logged-in user, which you can compare against a `user_id` column. Additionally, using `(select auth.uid())` instead of bare `auth.uid()` prevents the function from re-evaluating on every row, improving query performance. **Diagnostic query** — run this in the Supabase SQL editor to check your policies: ```sql SELECT schemaname, tablename, policyname, qual FROM pg_policies WHERE schemaname = 'public' ORDER BY tablename; ``` If any `qual` column shows `(auth.role() = 'authenticated'::text)` on a table that holds user-specific data, you have the problem. Fix each table by dropping the broken policy and replacing it with one using `auth.uid() = user_id`. ## Why it matters A data breach between user accounts does not require a hacker. It requires only a logged-in user who opens the browser developer tools and queries the API directly. The Supabase anon key is public by design — the only defense is correct RLS policies. ## Suggested next action Open your Supabase SQL editor, run the diagnostic query above, and review every `qual` value on tables storing user data.

The RLS Role Confusion That Leaks Every User’s Data

Sources

Confidence check

Evidence

Discussion