Can one customer read another customer's data?
Secure a Supabase app by reviewing grants and row-level policies on exposed tables, keeping privileged keys on the server, and testing access as separate users. Enabling RLS is only one part of that review; the policies must enforce your actual ownership model.
Who this is for: Teams using Supabase with Next.js, Lovable, React or a browser-based SaaS frontend.
STEP 01
Start with the access your app intends to allow
Write down which records belong to a person, organization or public audience before editing policies. For a team workspace, user identity alone may not express membership or role. Review each operation separately: a user who may read a record should not automatically be able to change its owner or delete it.
Try this: Create a small access matrix covering guest, member, member of another organization and administrator.
STEP 02
Check the keys that cross the browser boundary
A Supabase publishable key, or legacy anon key, is intended for client use with correctly configured access controls. A privileged secret or service-role key is different: keep it in trusted server code. Check environment-variable names, client imports and build artifacts. A generic key warning needs this context before you classify it as an incident.
Try this: Review every Supabase client initialization and identify whether it runs in the browser or on the server.
STEP 03
Test denial as deliberately as success
Create two users in different test organizations. Give each a record, then use the app's normal data access path to attempt cross-organization reads and writes. Include attempts to change ownership fields. Retest after schema changes; a new table, RPC function or storage path can create an access route that older tests never exercised.
Try this: Keep the two-user isolation tests next to the migration or feature that introduced the protected data.
Your review checklist
- Document ownership for each table and operation.
- Review grants and RLS policies on exposed tables.
- Keep privileged Supabase keys out of client code and public variables.
- Test signed-out, own-record and cross-tenant access.
- Review RPC functions, storage policies and administrative paths.
- Run access tests again after every relevant schema change.
What Bryxe can check
Bryxe can flag supported risky Supabase code patterns and exposed privileged credentials in supplied files. Use findings to focus the database review and investigate the affected call sites.
What you still need to verify
Scanning source cannot prove that deployed database policies match your migrations or that every tenant boundary works. Inspect the live configuration and run permission tests in a controlled environment.
Common questions
Is a Supabase anon key a leaked secret?
Not by itself. A publishable or legacy anon key is intended for client use. Its access must still be constrained by grants and policies. Privileged secret and service-role keys need server-side protection.
Why do I need a two-user RLS test?
One user's successful query only demonstrates that allowed access works. A second user's attempt to reach the first user's records checks that your ownership boundary rejects an unauthorized request.
Can a source scanner validate production RLS?
It can identify suspicious source patterns or migrations, but it does not establish the state of your deployed database. Compare the deployed policies with the intended schema and test the actual access paths.
Documentation & further reading
These primary sources explain the platform behavior discussed above. Check the documentation for the versions and configuration you use.