Supabase RLS: How to never ship a data leak

Why RLS bugs are dangerous

Row Level Security bugs don't throw errors. Your app works perfectly — User A just happens to see User B's data. No crash, no log, no alert. Silent data exposure.

The 5 most common mistakes

1. Forgetting to enable RLS

Creating policies on a table without enabling RLS first. The policies exist but do nothing.

-- BAD: policies exist but RLS is off
create policy "select_own" on projects for select using (user_id = auth.uid());
-- Table is still wide open!

-- FIX: enable first
alter table projects enable row level security;

2. using(true) on write policies

This is essentially GRANT ALL TO public with extra steps.

-- BAD: anyone can insert anything
create policy "insert_all" on projects for insert with check (true);

-- FIX: check ownership
create policy "insert_own" on projects for insert
  with check (auth.jwt() ->> 'sub' = user_id);

3. Missing with check on insert/update

Without with check, users can insert rows they can't read back — or worse, insert rows into other users' data.

4. Using service_role from client-reachable code

Exposing SUPABASE_SERVICE_ROLE_KEY in client components bypasses all RLS. Keep it server-side only.

5. Not testing with simulated users

If you never test as a different user, you'll never see the leak.

-- Simulate user_abc
set local role authenticated;
set local request.jwt.claims to '{"sub":"user_abc"}';
select * from projects;  -- should only see user_abc's rows
reset role;

Automate the audit

The Claude Code Subagents Pack includes a /check-rls command that audits every table automatically:

/check-rls all

[✓] profiles     — owner-only, 4 policies, clean
[✗] projects     — using(true) on INSERT
[✗] api_keys     — RLS NOT ENABLED
[✓] subscriptions — owner-read, service-write, clean

Recommendation: NO-GO — fix projects and api_keys

Then invoke @agent-supabase-rls to generate idempotent fix migrations automatically.