How to reliably test Supabase RLS policies without manual setup

Row-Level Security (RLS) in Supabase is designed to isolate tenant data, but when misconfigured, it doesn’t raise errors—it simply returns incorrect data. This silent failure often goes unnoticed until sensitive information leaks or legitimate users are blocked from accessing their own records. Traditional testing methods fall short because they rely on SQL editors that bypass RLS, leaving policies untested in production-like environments.

Why RLS policies often go untested

Writing manual tests for RLS policies is a labor-intensive process that many teams skip. To validate a single policy, developers must:

• - Create multiple user roles, including owners, tenants, anonymous users, and role-specific identities.
• - Insert test data with ownership attributes tied to each role.
• - Simulate interactions by setting session claims and roles.
• - Execute read, insert, update, and delete operations for each identity.
• - Assert that only the expected rows are returned or modified.

This process must be repeated for every table and policy, making it impractical for most teams. Even when tests are written, they often pass vacuously—checking against empty tables or overly permissive policies—without revealing real-world vulnerabilities.

What a proper RLS test should verify

A rigorous RLS test verifies security boundaries from each user’s perspective, ensuring:

• - Owners can view and modify only their own records.
• - Tenant users cannot access records belonging to other tenants.
• - Anonymous users are blocked entirely.
• - Role-based access grants only the intended permissions.

The test must use seed data where each record is owned by the identity under examination. Additionally, it must distinguish between two types of denials:

• - Row-level filtering: The query returns zero rows.
• - Permission errors: The operation throws an explicit rejection.

Without this distinction, teams may overlook subtle policy interactions that create unintended access paths.

Automate testing with rlsautotest

To eliminate manual effort, the open-source tool rlsautotest generates pgTAP tests and seed data directly from your RLS policies. It works with any PostgreSQL-compatible database, including Supabase, Neon, and Amazon RDS, and outputs results as an HTML report or a pgTAP test suite for CI integration.

To generate a permissions report, run:

rlsautotest --db-url "$DATABASE_URL" --schema public --html rls-report.html

For a test suite compatible with CI pipelines:

rlsautotest --db-url "$DATABASE_URL" --schema public --emit supabase/

The generated report presents access permissions in a clear table format, highlighting mismatches where unauthorized users gain access. The tool also exits with a non-zero status if it detects leaks or tables without RLS policies, making it easy to integrate into automated workflows.

Real-world vulnerabilities uncovered

Automated testing reveals subtle policy interactions that manual reviews often miss. For example, consider a table with two permissive UPDATE policies, each restricting values based on user roles. If the policies rely solely on the USING clause to define access and lack WITH CHECK constraints, PostgreSQL combines their WITH CHECK clauses using OR logic. This can allow any user who meets one policy’s USING condition to set values permitted by the other policy, even if it violates their intended role restrictions.

rlsautotest identifies such leaks by enumerating the value space for each identity and flagging unauthorized writes, ensuring policies are evaluated in combination rather than isolation.

Limitations and intentional design choices

rlsautotest focuses on verifying what the database enforces, not what developers intended. This means:

• - It will confirm a policy is correctly enforced, even if the policy itself is overly permissive.
• - Tables without policies are reported as blocked, unless explicitly opted into testing.
• - Policies behind opaque functions are flagged for manual review.

The tool avoids making unverified assumptions. If it cannot confidently assert access rules, it marks the result as unproven rather than providing a false positive. This conservative approach ensures that only validated security boundaries are considered secure.

Next steps for securing your database

If your RLS policies haven’t been thoroughly tested, now is the time to verify their effectiveness. Use a disposable database copy to run rlsautotest and review the generated report. In minutes, you’ll either confirm your policies are secure or uncover hidden vulnerabilities before they reach production. The tool’s simplicity and automation make it an essential addition to any Supabase or PostgreSQL security workflow.