DEV Community

RLS fails silently. Here's how to actually test your Supabase policies.

Munaf Khatri on July 10, 2026

A wrong RLS policy doesn't throw an error, it just returns the wrong rows, so it ships untested and you find out when data leaks. rlsautotest gener...

Read full post

Pon • Jul 15

The zero-rows versus permission-error split is a distinction most write-ups skip, glad you kept them apart. Does the generator also walk views and security definer paths? The leaks I've hit lived there, not in the table policies.

Munaf Khatri • Jul 18

Straight answer: not yet. It walks base tables and their policies today, not views or SECURITY DEFINER paths. Both are exactly where rights get swapped for the owner's: a view without security_invoker runs as its owner and skips the base table's RLS, and a SECURITY DEFINER function runs as the definer unless it re-checks auth. A tool that stops at the table catches neither, which is why that's where I want to take it next. If you've got a sanitized example that bit you, I'd love it as a test case.

Pon • Jul 18

Here's a clean one to seed: a base table with per-user RLS, then a reporting view over it for some dashboard, created without security_invoker. The view runs as its owner, so PostgREST serves it straight to anon and every user's email comes back, and the base table's RLS never gets consulted. The tell you could assert on is that exact pair: a view whose base table has relrowsecurity and policies, but the view itself isn't security_invoker. Green base table, wide-open view.

Munaf Khatri • Jul 18

Ok. I will work around your description to create the scenario. This should be mostly be fixed by next week. Will keep you posted. MEanwhile if you want to track it in github, i would encourage you to log enhancement over there. Here is the repo link- github.com/unitautogen/rlsautotest

Munaf Khatri • Jul 18

@vollos - One ask if you are ok to answer. Do you face issues around unit testing your functions and triggers? How do you ensure proper code coverage and track the metrics?

Pon • Jul 18

Glad the view case is worth chasing. On your question, honest answer: coverage metrics aren't really my beat. I spend more time reviewing other people's code for security than maintaining a big suite of my own, so I'm not the one with a coverage regime to model. From the review side though, functions and triggers are the least-tested surface I see in AI-built Supabase apps, usually zero tests at all. And where there is coverage, line coverage misses the case that bites: whether the function ever ran as an identity that shouldn't be allowed. A SECURITY DEFINER function can be 100% line-covered and never once exercised against the wrong caller. So the thing I'd track is coverage by identity, not by lines.

PubliFlow • Jul 16

Silent failures in RLS are definitely one of the biggest foot guns when migrating from a traditional backend to Supabase. I usually tackle this by writing custom PL/pgSQL functions that explicitly assert the expected row counts and throw exceptions if the policy logic falls short during CI. Another approach that has saved me a lot of debugging time is using the Supabase CLI to run local migrations with seed data specifically designed to trigger edge cases in the policies. Have you found a specific testing library or framework that integrates better with Jest or Vitest for mocking the auth context during these RLS tests?

Munaf Khatri • Jul 18

Honestly, I haven't found a Jest/Vitest library I'd trust here, because there's nothing to mock. auth.uid()/auth.jwt() just read request.jwt.claims and the current role, so the only faithful way to impersonate is on a real session: SET LOCAL ROLE authenticated + set_config('request.jwt.claims', '{"sub":...}', true), query, assert, roll back. Mock it in JS and you're testing the mock, not the policy. From Vitest that's a pg client, one transaction per test, set role and claims, assert, rollback. It's also why I emit pgTAP: the assertion runs in the same session as the policy, so nothing gets faked.
Your instincts are already right, by the way. The throwing PL/pgSQL asserts are hand-rolled pgTAP, and those edge-case seeds are the part that quietly rots when a policy changes.

Cenk KURTOĞLU • Aug 7

The seed-data point is the one most hand-rolled suites get wrong, and it deserves the billing you gave it — an assertion that passes against an empty table is exactly how these end up green and worthless.

Two things worth adding for readers.

"The SQL editor bypasses RLS" is not quite the reason it misleads you.

The editor connects as postgres, and RLS is skipped for a role holding BYPASSRLS or for the table owner (absent FORCE ROW LEVEL SECURITY). But set role authenticated drops both of those, and from that point policies are enforced — which is why the set role pattern works at all.

What actually makes editor testing lie is narrower, and fixable: request.jwt.claims is unset, so auth.uid() and auth.jwt() evaluate against NULL rather than against a user. A policy of using (user_id = auth.uid()) then filters everything away, and you conclude it is too strict when it is fine.

Scoped to a transaction so it cannot leak into the rest of the session:

begin;
select set_config('request.jwt.claims',
                  '{"sub":"11111111-1111-1111-1111-111111111111","role":"authenticated"}',
                  true);
set local role authenticated;

select * from notes;   -- exactly what that user sees

rollback;

Swap the sub and you have the cross-tenant check by hand. That does not replace a generated suite, but it is worth knowing the editor is usable rather than useless — "you cannot test this here" is the reason a lot of people never test it anywhere.

What a per-identity matrix structurally cannot show

The report answers "can identity X touch table Y", which is the right question for policies. The leak it cannot see is the one that goes around them: a SECURITY DEFINER function executes as its owner, and a view in Postgres runs with the view owner's rights unless you set security_invoker = true — so the caller's policies never run. One helper that returns rows from a tenant-scoped table hands every caller the whole table, and every cell in the matrix still reads correctly, because the policy is correct. It simply is not in the path.

Worth a companion check against the catalog rather than against the policies:

select n.nspname, p.proname, pg_get_userbyid(p.proowner) as owner
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where p.prosecdef
  and n.nspname not in ('pg_catalog', 'information_schema')
order by 1, 2;

select c.relname, c.reloptions
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where c.relkind = 'v' and n.nspname = 'public';

Anything security-definer owned by postgres or supabase_admin and callable by anon, and any view without security_invoker=true over an RLS table, is worth reading line by line.

Cenk KURTOĞLU • Aug 7

Correcting myself: the second half of my comment above is wrong.

I said a per-identity matrix structurally cannot show the bypasses that go around policies. rlsautotest reports exactly those, and has since v0.3.0 — there is a "Beyond the policies: bypass surfaces" section covering owner-rights views and materialized views readable by anon or authenticated over an RLS-protected table, SECURITY DEFINER functions a client can EXECUTE, mutable search_path on those functions, BYPASSRLS and superuser roles, and RLS-enabled-but-not-FORCEd tables. It judges reachability by effective privilege via has_table_privilege / has_function_privilege, which picks up PUBLIC grants — and a function reachable only through Postgres's default PUBLIC EXECUTE grant is precisely what a hand-written check tends to miss, because nobody granted it explicitly.

I read the article and not the README before writing that. The catalog queries are still fine as a manual check; the claim that the tool needs them is not.

The set role correction in the first half stands.