RLS Verification

RLS must be verified from the final applied database state, not by reading migrations alone.

The current executable check is:

pnpm --dir tests/integration test rls-security.test.ts
pnpm --dir tests/integration test tenant-isolation.test.ts

When Supabase is reachable, the test calls public.verify_rls_security_posture() with the service-role client. The function fails if required tables are missing, if RLS is disabled on checked tables, if sensitive tables expose anonymous SELECT policies, if a trigger function is directly executable by a client role, or if an anonymous SECURITY DEFINER function is not on the exact-signature allowlist.

The same test also verifies that anonymous clients cannot execute the posture helper.

The transactional database contract runtime-security-posture.sql runs the same final-state verifier and independently asserts that neither anon nor authenticated can execute a public trigger function directly. Migration 00257_runtime_security_posture_reassertion.sql is the source of truth for the current exact REGPROCEDURE allowlist. Adding a new anonymous delegated function therefore requires an explicit security review and signature entry.

tenant-isolation.test.ts signs in with seeded company-owner users and verifies that each company can only see its own company_users, buses, drivers, and booking rows. The test creates temporary trips/bookings with the service-role client, then reads them through normal authenticated company clients.

Limits

This covers company-user tenant isolation for core operational tables. The next required layer is role-specific RLS testing for passenger, driver, and admin clients against seeded data from different tenants.