Supabase RLS tests that prove User A cannot read User B data

A Supabase RLS policy is not proven just because the dashboard looks correct. The real test is whether User A can reach User B's data through the UI, direct API calls, storage paths, RPC functions, Edge Functions, realtime subscriptions, or any backend route that uses elevated access.

If you are launching an AI-built SaaS app, the minimum RLS launch test is simple: create two real users, create private data for both, then try to make each user read, update, delete, list, download, or overwrite the other user's records.

Why do Supabase RLS tests matter before launch?

Supabase lets browser apps access the database safely when Row Level Security is enabled and policies are correct. The official RLS docs say RLS should be enabled on tables in exposed schemas, including the default public schema. They also explain that after RLS is enabled, no data is accessible through the API using a publishable key until policies allow it.

That secure default is useful, but it does not prove your product logic is correct. A policy can compile and still allow the wrong tenant, team member, workspace, or user to read data. That is why a launch audit needs behavior tests, not only a policy list.

What is the User A / User B RLS test?

The User A / User B test is a practical isolation check. User A owns one set of data. User B owns another set of data. The test proves that each user can only access the data they should see.

1. Create User A with a normal customer account.
2. Create User B with a second normal customer account.
3. Create records for User A in every private table.
4. Create records for User B in the same tables.
5. Login as User B and try to access User A's data.
6. Repeat reads, inserts, updates, deletes, file downloads, and direct API calls.

If User B can access User A's private rows by guessing an ID, changing a URL, editing a request body, or calling Supabase directly, the app is not ready to launch.

Which tables should be tested?

Test every table that stores private or account-specific data. Do not only test the obvious table that powers the dashboard. AI-built apps often create supporting tables during feature work, and those tables can be less protected than the main entity.

• profiles, users, accounts, and workspaces.
• Documents, chats, messages, forms, leads, and generated reports.
• Invoices, subscriptions, usage records, credits, and entitlements.
• Teams, memberships, roles, invites, and organization settings.
• Files, exports, uploads, images, transcripts, and storage metadata.
• Automation logs, webhook events, CRM sync state, and background jobs.

How do I test SELECT policies?

Start with reads because read leaks are the easiest to miss. The UI may only show the current user's rows, but the API may still return another user's row when you request it directly.

1. Login as User A and create a private record.
2. Copy the record ID.
3. Login as User B in another browser or private window.
4. Try to load User A's record from the UI by changing the URL.
5. Try a direct Supabase API request for that row using User B's session.
6. Try list endpoints with filters removed or changed.

A correct private SELECT policy should return no row to User B. A broad policy such as USING (true) may be correct for public content, but it is a launch blocker for private tables.

How do I test INSERT policies?

Supabase policies for inserts use WITH CHECK. The important question is whether User B can create a row that belongs to User A, another workspace, or a paid account they do not control.

1. Login as User B.
2. Send an insert request with user_id, owner_id, workspace_id, or organization_id set to User A's values.
3. Check whether the row is rejected.
4. Repeat for team-owned records, invite records, billing records, and generated content.

If the insert succeeds, User B may be able to poison another user's account, create records inside another workspace, or trigger downstream automation under the wrong owner.

How do I test UPDATE policies?

Update policies need special attention because they can check both the existing row and the new row. Supabase's docs explain that update policies can combine USING and WITH CHECK: one checks whether the row can be updated, the other checks whether the new row is allowed after the update.

Before launch, test both paths:

• User B cannot update User A's existing row.
• User B cannot update their own row and change ownership to User A, another workspace, or another organization.
• User B cannot upgrade their role, plan, credits, entitlement, or admin status through a direct update.
• User B cannot edit another user's invite, membership, file metadata, or billing state.

How do I test DELETE policies?

Delete tests are simple and important. User B should not be able to delete User A's records, files, team membership, invoices, usage logs, or automation jobs. Test deletes from the UI and direct API calls.

For each private table, ask: if this row disappears, can the user lose work, lose access, lose audit history, or corrupt billing state? If yes, test delete isolation before launch.

How do I test Supabase Storage RLS?

Storage needs separate tests. Table RLS does not automatically prove that private files are safe. User A / User B tests should cover listing, uploading, downloading, replacing, and deleting files.

1. User A uploads a private file.
2. User B tries to list the bucket or folder.
3. User B tries to download the file by path.
4. User B tries to overwrite the same path.
5. User B tries to delete the file.
6. Signed URLs expire and cannot be guessed from public paths.

Do RPC functions and Edge Functions need RLS tests?

Yes. RPC functions and Edge Functions can become a shortcut around otherwise good table policies. This is especially common when a backend function uses a secret key or legacy service role key to make a feature work.

Test every function that returns user data, creates records, changes memberships, updates billing state, processes files, or triggers AI jobs. A function can use elevated access internally, but it must still verify who is calling it and which user, workspace, or organization they are allowed to act on.

Can automated tests prove Supabase RLS?

Automated tests help a lot, but only when they model real product scenarios. Supabase documents database testing and linting through the CLI, and Postgres ecosystems often use pgTAP-style tests. Those tools are useful for repeatable checks, but a test with weak seed data can pass while production isolation is still broken.

Good RLS tests need:

• At least two normal users.
• Rows for both users in every private table.
• Tenant, workspace, and role variations if the app has teams.
• Negative tests that try forbidden reads and writes.
• Storage and backend function tests, not only table selects.

What should fail in a good RLS test?

A good RLS test is not only checking successful access. It should prove that forbidden access fails.

• User B cannot read User A's private rows.
• User B cannot insert rows owned by User A.
• User B cannot update User A's rows.
• User B cannot move their own row into User A's workspace.
• User B cannot delete User A's rows.
• User B cannot list, download, overwrite, or delete User A's files.
• Logged-out visitors cannot access authenticated-only data.
• Canceled or unpaid users cannot trigger paid workspace actions through backend routes.

Supabase RLS tests before launch

1. Create User A and User B as normal app users.
2. Create private rows for both users in every private table.
3. Test direct row reads by ID.
4. Test list queries with filters removed or changed.
5. Test insert ownership with forged user_id, workspace_id, or organization_id.
6. Test update ownership and role changes.
7. Test deletes on private records.
8. Test storage list, download, upload, overwrite, and delete paths.
9. Test RPC functions, Edge Functions, and backend routes.
10. Test unauthenticated access where auth.uid() is null.
11. Test team membership, admin roles, invites, and billing state.
12. Repeat after schema, policy, storage, or backend route changes.

Launch verdict

Block ship if User B can read, update, delete, list, download, or overwrite User A's private data.

Ship with fixes if table RLS passes but storage, RPC, Edge Functions, or backend routes have not been tested yet.

Clear to ship when User A / User B isolation passes for tables, storage, functions, backend routes, logged-out requests, team roles, and billing-related data.

Useful references

• Supabase docs: Row Level Security
• Supabase docs: Testing and linting
• Supabase docs: Storage access control