Enable RLS on every exposed table
Supabase says RLS should be enabled for tables in exposed schemas such as public. Tables created through raw SQL need special attention because protection may not have been enabled automatically.
Supabase security checklist
Check the authorization boundary, not just the UI.
A polished login screen does not prove that one user cannot read or change another user's data. Before launch, review database and storage policies with real user sessions, then check what the public app exposes.
RLS
Browser keys
Storage
Two-user test
Security Advisor
Supabase launch review
Supabase production checklistKnow which browser key is safe
A publishable or legacy anon key can appear in frontend code when RLS and least-privilege grants protect the data. Service-role and secret keys bypass RLS and must stay on trusted servers.
Run a two-user authorization test
Create two ordinary accounts. Try to read, update, and delete the other user's records by changing IDs and request payloads. Test anonymous access separately from authenticated access.
Review Storage policies independently
Database table policies do not replace Storage access rules. Test uploads, downloads, listings, overwrites, and deletes with anonymous and cross-user sessions.
Inspect views and server functions
Views and privileged functions can create paths around an otherwise careful policy model. Review exposed schemas, invoker behavior, grants, and every endpoint that uses elevated credentials.
Clear Security Advisor findings
Use Supabase Security Advisor before launch and after schema changes. Investigate disabled RLS, permissive policies, exposed sensitive columns, public bucket listing, and security-definer warnings.