Home / RLS / Failure taxonomy

Supabase RLS · Reference

The 18 ways Supabase RLS breaks

-- reproduce: create a table without enabling RLS
create table secrets (id int, value text);
-- anon can: SELECT * FROM secrets → all rows
-- fix:
alter table secrets enable row level security;

-- reproduce:
create policy "allow all" on notes for select using (true);
-- anon can: SELECT * FROM notes → all rows
-- fix: scope to the caller
drop policy "allow all" on notes;
create policy "owner reads" on notes for select
  using (user_id = (select auth.uid()));

-- reproduce:
create policy "anon reads" on profiles for select to anon
  using (is_active = true);  -- not scoped to a user
-- anon can: read every active profile
-- fix: restrict to authenticated, or scope

-- reproduce:
create policy "users read" on orders for select to authenticated
  using (true);
-- user B can: SELECT * FROM orders → sees user A's orders
-- fix:
using (user_id = (select auth.uid()))

-- reproduce:
create policy "insert any" on tasks
  for insert to authenticated
  with check (true);
-- user B can: INSERT INTO tasks (user_id, title)
--   VALUES (user_A_id, 'forged') → succeeds
-- fix:
with check (user_id = (select auth.uid()))

-- reproduce:
create policy "member reads" on projects for select
  using (is_member(org_id));  -- what does is_member do?
-- could be fine, could be USING(true) in disguise
-- fix: verify the function body restricts to auth.uid()

-- reproduce:
create function get_all_orders()
  returns setof orders
  language sql security definer
  as $$ select * from orders $$;
-- any authenticated user: SELECT * FROM get_all_orders()
--   → returns ALL orders, regardless of RLS

-- reproduce:
grant execute on function get_all_orders() to anon;
-- now an unauthenticated visitor can call it
-- fix:
revoke execute on function get_all_orders() from anon;

-- reproduce: function without SET search_path
create function count_orders()
  returns bigint
  language sql security definer
  as $$ select count(*) from orders $$;
-- attacker sets search_path = attacker_schema, public
-- fix:
alter function count_orders() set search_path = '';

-- reproduce:
create view all_profiles as select * from profiles;
-- anon can: SELECT * FROM all_profiles → all rows
--   (the view's owner bypasses profiles' RLS)
-- fix:
alter view all_profiles set (security_invoker = true);

-- reproduce:
update storage.buckets set public = true
  where id = 'documents';
-- anyone can: GET /storage/v1/object/public/documents/...
-- fix:
update storage.buckets set public = false
  where id = 'documents';

-- reproduce: table with RLS off + Realtime enabled
alter publication supabase_realtime add table messages;
-- anon subscribers see every row change in real time
-- fix: remove from Realtime or fix the RLS leak first
alter publication supabase_realtime drop table messages;

-- reproduce:
alter role authenticated bypassrls;
-- now every authenticated user bypasses every policy
-- fix:
alter role authenticated nobypassrls;

-- reproduce:
alter table invoices owner to authenticated;
-- authenticated bypasses all RLS on invoices
-- fix:
alter table invoices owner to postgres;
-- or:
alter table invoices force row level security;

-- the probe (not SQL — this is an HTTP request):
GET /rest/v1/profiles?select=*&limit=1
apikey: <anon_key>
-- if HTTP 200 with rows → PROVEN LEAK
-- if HTTP 200 with [] or 401/403 → safe

-- the probe:
POST /rest/v1/profiles
apikey: <anon_key>
body: {}
-- if HTTP 201 → PROVEN LEAK (row created)
-- if 400/409 without "row-level security" → RLS passed

-- the probe (simplified):
-- 1. Create user_a, create user_b
-- 2. As user_a: INSERT INTO tasks (user_id, title)
--    VALUES (user_a_id, 'secret task')
-- 3. As user_b: SELECT * FROM tasks
--    WHERE user_id = user_a_id
-- if rows come back → CROSS-TENANT LEAK

-- the probe (simplified):
-- 1. As user_a: INSERT INTO tasks (...) → row_id
-- 2. As user_b: PATCH /rest/v1/tasks?id=eq.row_id
--    body: {"title": "changed-by-b"}
-- if HTTP 200 and row changed → CROSS-TENANT LEAK

Coverage summary

Airlock checks all 18 failure modes. 14 are caught by static analysis alone (reading the database catalog in a single read-only transaction). 2 are caught by dynamic probes (real HTTP requests with the anon key). 2 require cross-tenant probes with temporary test users.

Static analysis is fast and safe — it never writes to your database. Dynamic probes confirm what static analysis suspects. A finding that both layers agree on is stronger than either one alone.

If you find a failure mode we don't cover, open an issue. We'll add it.