Supabase security · 8 minute read

How to test Supabase RLS policies before launch

A policy existing is not proof that tenant data is isolated. Test the forbidden paths: user A reading or changing user B's rows, a tenant member crossing into another tenant, and an unauthenticated request reaching data that should be private.

The minimum useful test matrix

For every protected table, exercise the operation and identity together:

• Anonymous: SELECT, INSERT, UPDATE and DELETE are denied unless intentionally public.
• Owner: a signed-in user can perform only the operations the product promises.
• Different user: the same request against another user's row returns no data or fails.
• Different tenant: membership in tenant A never grants access to tenant B.
• Privileged path: service-role usage stays on a trusted server and is not treated as an RLS test.

Test negative cases, not only the happy path

A passing owner query proves that the application works for its owner. It does not prove isolation. Seed two users and two tenants, obtain a separate session for each, then deliberately request the other identity's row ID. Repeat for reads and writes.

userA can read rowA         // expected: yes
userA can read rowB         // expected: no rows
userA can update rowB       // expected: denied or no rows
tenantA user reads tenantB  // expected: no rows
anonymous reads private row // expected: no rows

Verify the database boundary

1. Confirm RLS is enabled on every table exposed through the API.
2. List policies by command and role; broad USING (true) rules deserve explicit review.
3. Check both USING and WITH CHECK behavior for writes.
4. Test through the same client and JWT roles the application uses.
5. Keep the test deterministic so it can run again after schema or policy changes.

Supabase's official guide explains the underlying policy model in more detail: Row Level Security.

Run a public isolation fixture

The public Supabase RLS leak demo uses synthetic records and executable TypeScript tests. Its broken branch demonstrates a cross-user leak; the fixed branch applies the policy boundary and passes five isolation checks. No client or production data is included.

See the synthetic sample audit report for the finding, evidence, remediation and verification format used to communicate a result.

Copy the ready-to-adapt negative-test matrix into an issue, pull request or test plan to cover anonymous, cross-user, cross-tenant, ownership-change and removed-member cases.

When a focused audit is worth it

Use an independent review when several tables share tenant rules, the application mixes browser and server access, or a launch depends on proving that cross-user paths are closed. The review should produce reproducible evidence and prioritized fixes—not a generic security score.

Review the fixed-price Supabase RLS audit and its exact scope →

Lower-cost launch check

If you only need a broad pre-launch checklist, the Next.js + Supabase launch checklist covers RLS, secrets, authentication, performance and launch checks in an eight-page PDF with a public preview.