Supabase RLS: an access-review checklist for your MVP
A login screen does not by itself define which records a customer can read or change. For an app using Supabase, review the database rules alongside the product’s ownership and membership model.
Write down who owns each kind of record
List the records that matter: profiles, projects, invoices, uploads and organization membership. For each, specify who may read, create, change and delete it. A project may belong to one customer or to an organization with several members. Those are different access models. Resolve the intended behavior before deciding whether a policy is correct.
Check RLS and policies together
Supabase documents Row Level Security as a way to constrain access to rows, used with authentication and database privileges. Confirm that relevant exposed tables have RLS enabled and that their policies express your actual ownership rules. ‘The user is logged in’ is not equivalent to ‘the user belongs to this customer organization.’ Review all relevant operations, including whether an update could change an ownership field.
Exercise a small access matrix
Use synthetic accounts: signed out, customer A, customer B, a member of organization A and a member of organization B. For each important record type, try the allowed action and a forbidden equivalent. Ask for tests that reach the API directly, because hiding a control in the interface is not an authorization rule. Include membership removal: losing access to an organization should have the intended effect on subsequent requests.
Keep privileged credentials out of the browser
Supabase warns that service keys can bypass RLS and must not be exposed to customers. Inspect which credentials are shipped to the frontend and where privileged server code runs. Server endpoints using elevated access still need to enforce the caller’s permissions. Do not paste real secrets into a report or email; document the location and exposure without reproducing the credential.
Check files and future changes separately
Do not assume that reviewing table policies also verifies uploaded files, server routes or integrations. List them explicitly in the review scope. Once an access issue is fixed, keep a regression check for the boundary that failed. A later feature or agent-generated migration can change the assumptions, so the useful deliverable is both the repair and a way to notice if the rule stops holding.
Related field note: the detail behind this check ↗
Platform references
Platform behavior is referenced below. The review steps above are our recommendations. Ready or Not is independent and is not affiliated with these platforms.
Keep reading
Is your Lovable app ready for real customers? ↗