Home / RLS / Test tenant isolation

Supabase RLS · Testing

How to test tenant isolation in Supabase

01 The only proof that holds

You can't eyeball a policy and know it's correct. The proof is behavioral: sign in as tenant A, and confirm A can reach A's rows and cannot reach or write B's. Do it through the client, as authenticated — the SQL editor bypasses RLS, so testing there proves nothing.

02 The test (two signed-in clients)

rls.test.ts

import { createClient } from '@supabase/supabase-js'

const signIn = async (email) => {
  const c = createClient(URL, ANON_KEY)
  await c.auth.signInWithPassword({ email, password: 'test-pw' })
  return c
}

test('A cannot read B rows', async () => {
  const a = await signIn('a@test.dev')
  const b = await signIn('b@test.dev')

  const { data: row } = await b.from('notes')
    .insert({ title: 'B secret' }).select().single()

  const { data } = await a.from('notes').select().eq('id', row.id)
  expect(data).toHaveLength(0)          // blocked, not just absent
})

test('A cannot insert for B', async () => {
  const a = await signIn('a@test.dev')
  const { error } = await a.from('notes')
    .insert({ title: 'x', user_id: B_ID })
  expect(error).toBeTruthy()                // new row violates RLS
})

03 What to assert

04 Run it in CI

Point the test at a real Supabase/Postgres (a CI branch database or a local supabase start) and run it on every migration. A new table that ships without a correct policy should turn the build red. To catch the coarser failure — a table with RLS off entirely — add an RLS gate in CI.

FAQ