Glossary
RLS (Row Level Security)
A database access control mechanism at the row level. RLS restricts which data each user can see, directly at the database layer. It is an essential building block for applications using Supabase or PostgreSQL.
RLS, the backbone of multi-tenant on Supabase and PostgreSQL
Row Level Security is a PostgreSQL mechanism that filters which rows are visible based on SQL policies attached to each table. On Supabase it is THE central security mechanism: the frontend talks directly to the database through the auto-generated API, so without properly configured RLS, every table is readable or writable by any authenticated — or even anonymous — user. For an HR SaaS built on Supabase, RLS policies are literally what separates one client company's data from another's.
The RLS mistakes we find most often
Our Supabase audits keep finding the same patterns: tables with RLS never enabled (exposed through the public REST API), policies written for SELECT but forgotten for UPDATE or DELETE, policies based on a column the user can modify themselves, views and RPC functions that bypass RLS (SECURITY DEFINER), and Storage buckets whose policies don't match the tables. One forgotten table is enough: the employee list, applications, or documents become public.
How CleanIssue audits your RLS policies
In real-world conditions, with test accounts across multiple tenants, we check every API-exposed table: cross-tenant reads, cross-tenant writes, escalation through RPC and Edge Functions, consistency between table RLS and Storage policies. The report lists each table with its actual protection level — not the assumed one — and the SQL policies to fix, in a format your team can act on directly.
Frequently asked questions
Is RLS enabled by default on Supabase?
Not for tables created in raw SQL: you must enable it explicitly (ALTER TABLE ... ENABLE ROW LEVEL SECURITY) and then write policies. The Supabase dashboard warns about exposed tables without RLS, but the warning is often ignored during fast development and forgotten in production.
Is RLS enough to secure a multi-tenant SaaS?
It is the foundation, not the whole story: you also need Storage policies, RPC and Edge Functions (which can run with elevated privileges), the service_role key that bypasses all RLS, and server-side business logic. An audit checks the whole chain, not just tables.
How do you test your RLS policies?
Create test users in different organizations and systematically attempt cross reads, writes, and deletes on every table through the API. Policy unit tests (pgTAP or SQL scripts) help, but an external real-world test remains the best way to catch what was missed.