Available for PostgreSQL

Tenant isolation testing

Row-Level Security and careful function logic keep tenant A from seeing tenant B. Two layers, each needing its own proof, every release.

How to do it

Start free with rlsautotest for the policies. seccover covers the policies and the code in one run.

  1. Policies only, free. rlsautotest tests every RLS policy, per table, command and identity.
pip install rlsautotest
rlsautotest --db-url "$DATABASE_URL" --schema public --html rls-report.html
# or emit a committable pgTAP suite:
rlsautotest --db-url "$DATABASE_URL" --schema public --emit supabase/
  1. Policies and code, Enterprise. seccover tests the RLS policies with an improved version of the rlsautotest checks, plus the functions, views and triggers that bypass them.
unitautogen seccover --schema public --out sec_out --sec-html sec.html --sec-json sec.json --sec-gate

Two layers where tenant data leaks

A test at one layer says nothing about the other.

rlsautotest

Policy layer
  • Proves each RLS policy, per table, per command and per identity
  • Fails CI on a reachable table with no policy
  • Names every SECURITY DEFINER function, view and trigger as a suspect

It cannot judge the suspects; it sees that code bypasses RLS, not whether it leaks.

rlsautotest, free and open source →

UnitAutogen seccover

Policy and code layers
  • Tests every RLS policy, an improved version of the rlsautotest checks
  • Runs each suspect as two tenants with generated data on both sides
  • A verdict per routine, enforced or leaking, with the table, command and channel
  • A PII pass for personal data escaping through error messages

Covers both layers in one run, in the Enterprise edition.

seccover, in the UnitAutogen engine →

Start free with rlsautotest for the policies. Use seccover to cover both layers.

What platforms suggest

Both layers of isolation, and testing them, come straight from the platforms' docs.