Quick answer
RLS means Row Level Security. Before launching a Supabase app, you need to know whether users can only access the rows, files, and functions they are allowed to access. Frontend hiding is not the same as database-level protection.
Why this happens
AI-generated Supabase apps often make the UI look correct before the access model is actually safe. The app may filter data on the client, trust tenant IDs supplied by the browser, or create policies that pass the demo but fail negative tests.
What to check first
- Table policies for read, insert, update, and delete.
- Storage bucket policies for private files and user uploads.
auth.uid()usage in policies and queries.tenant_id,owner_id, team membership, and admin role boundaries.- RPC functions that trust client-provided tenant or owner values.
SECURITY DEFINERfunctions that may bypass RLS.- Edge functions and API routes that access service-role credentials.
- Negative tests proving user A cannot access user B data.
What not to do
- Do not assume Supabase is safe because the UI only shows the right rows.
- Do not bypass RLS to make a query work.
- Do not put service-role keys in frontend code.
- Do not launch with broad
truepolicies unless the exposure is intentional. - Do not let AI rewrite policies without a data ownership model.
Safe next step
Review data ownership, RLS policies, storage policies, functions, and negative tests before launch. The goal is to identify access risk and recommend the next safe path.
FAQ
Is this only for Supabase?
This page is Supabase-specific, but the same review mindset applies to any database access model.
Does passing the UI test mean RLS is correct?
No. The database and storage policies need to block unauthorized access even when the client is modified.
Should AI generate my RLS policies?
Only with a clear ownership model and review. Vague product rules produce vague policies.
Is this a certified security audit?
No. It is a practical production risk review focused on common Supabase launch risks.