A login screen proves very little about who can read or change a record. Before putting real private information into a Supabase app, test the access rules with sample data and two accounts. This guide uses a private reading list: each reader can manage only their own items. It is a focused starting checklist, not a certification or a substitute for reviewing a more sensitive application's design.
What you will leave with
Documented access rules, appropriate key placement and concrete tests showing that two users cannot read or change each other's private records.
Step 1
Write the access rule before writing the policy
For every table and upload, state who can create, read, update and delete it. In the reading-list example, a signed-in reader owns their entries; visitors see none. Decide whether administrators need a separate capability rather than quietly making every signed-in account powerful. If some information is public, name it explicitly. This small access matrix gives both the agent and reviewer a concrete standard against which to check the implementation.
Each operation has an intended actor, and private data is not public by default in the design.
Step 2
Separate public keys from privileged keys
Supabase's publishable key identifies the public app component and can be used in browser code. It does not replace the user's identity or data policies. Secret keys and legacy service_role keys have elevated access and must stay in trusted backend components with their own authorization checks. Inspect environment variable names and built client code. Putting a privileged value in an environment file does not keep it secret if the framework sends that variable to the browser.
The browser receives only the intended public configuration, and privileged keys are absent from source, logs and client bundles.
Step 3
Check table access and row access separately
Supabase's Data API uses grants to determine which roles can reach an object, then Row Level Security to determine which rows they may access. Inspect exposed schemas and table grants, enable RLS for exposed tables, and create policies matching the access matrix. Do not fix a permission error by granting broad access or disabling RLS. Project defaults can differ, so inspect the actual configuration instead of assuming a newly created table is safely configured.
The intended roles can perform the allowed operations and no unintended role receives access.
Step 4
Test ownership through the real app connection
Create account A and account B with clearly different sample entries. As A, read and edit A's entry. Then try to read, update and delete B's entry using its known ID through the same public client/API path the app uses. Try an insert with B's owner ID. Repeat signed out. A dashboard or privileged server key may bypass the policies you mean to test, so it cannot stand in for an ordinary user's session.
Try this instruction
Review this private reading-list app against this rule: a reader may manage only their own entries. Inspect grants, RLS, key placement and the ordinary client path. Use two test users and sample records. Report each attempted operation and its result. Do not disable policies or use an administrator key to make user tests pass.
Allowed operations succeed; cross-user and signed-out requests expose no private records and make no unauthorized changes. An empty result may be the expected denial.
Step 5
Review the less obvious access paths
Check views, database functions, server endpoints and uploads as well as the main table. A safe-looking page can call a privileged endpoint that trusts a user-supplied record ID. Verify the endpoint checks the caller and the requested operation. For private uploads, inspect bucket access and storage policies; knowing a filename should not grant access. Test replacement and deletion separately from uploading a new file, because they are different operations.
Alternate paths enforce the same intended ownership rules as the main user interface.
Step 6
Prepare for a mistake or leaked key
Use sample data while developing and separate test resources from meaningful production data. Know where configuration and schema migrations are recorded. Check the backup coverage and practice an appropriate restore in a safe environment. Supabase database backups contain storage metadata, not the uploaded objects themselves, so file recovery needs its own plan. If a privileged key leaks, revoke or rotate it and fix the exposure; deleting the visible string alone does not invalidate it.
You know which data can be recovered, from when, and which credentials would need replacement.
Step 7
Record the result and recheck after changes
Save the access matrix, test steps, date and unresolved findings beside the project. Review Supabase's current production checklist and security recommendations for the capabilities you actually use. Repeat the relevant access tests when adding a table, upload feature, role or endpoint. Security is not a badge earned by enabling one switch. It is behavior you can demonstrate for the actual paths through your application.
There is a repeatable test record, and unresolved access failures block using real private data.
When you get stuck
Any signed-in user can see every row
Check for a policy that tests only the authenticated role. Add the intended ownership or membership rule and test both users again.
A test passes only with a secret key
Retest with the public app key and a normal user session; privileged access does not prove user policies work.
A record disappears after adding RLS
Inspect grants and matching policies. An empty result can be correct access filtering; do not disable protection reflexively.
Terms explained
- Authentication
- Establishing who the caller is.
- Authorization
- Deciding what that caller may do to a particular resource.
- RLS
- Row Level Security: database policies that restrict access to individual rows.
Sources and further reading
The workflow and templates are teaching guidance. The sources below support the underlying tools and concepts; product setup and availability can change.
Take it into your next task
Your completion checklist
0 / 7 checked
Checks are saved on this browser. Mark them only after you inspect the evidence. These are your checks, not an automated certification.