Common Supabase RLS mistakes
The common Supabase row level security mistakes are: RLS left off on a table, policies that allow everyone (using (true)), policies that trust a user ID sent by the client, update policies without a matching check, team access checked against a column users can edit, and views or functions that bypass RLS. Any of them lets someone with your public anon key read or change data directly.
The mistakes and their fixes
| Mistake | Fix |
|---|---|
| RLS disabled on a table | Enable it; with no policies, access is denied |
using (true) on select for private data | Restrict to auth.uid() = user_id or membership |
Insert policy without with check | Add a check so users cannot insert rows owned by others |
Update allows changing user_id or role | Check ownership in both using and with check; restrict columns |
| Membership read from a table users can write | Protect the membership table with its own policies |
| Security definer views or functions | Use security invoker, or check permissions inside |
| Service role key in the front end | Move it server-side and rotate it |
This has happened publicly
CVE-2025-48757 records insufficient RLS policies in Lovable-generated projects that let unauthenticated requests read or write data. The pattern applies to any front end talking to Supabase directly.
How to test your policies
Use the Supabase client in the browser console as each of two users and with no session, and try to select, insert, update and delete each other's rows. The Supabase security checklist has the full list.
A correct policy, in words
For a tasks table in a team app, a sound set of policies says: a user may select a task if they are a member of the task's organization; may insert a task only into an organization they belong to, with themselves as creator; may update a task in their organization but may not change its organization; may delete only tasks they created, or any task if they are an organization admin. Membership lives in a separate table that users can read only for their own organizations and cannot write to directly.
Describe policies like this in plain language first, then ask your AI tool to write them. Review the generated SQL against the description, and test each sentence with two accounts.
Getting it checked
TrazTech offers vibe-coding QA and security review, listed from $2,000 CAD. Get at least one other quote on the same scope; the questions to ask a testing firm help compare them.
Related questions
Get a scope for your app
Tell us what you built, what it stores and who is about to use it.
Get matchedCommon questions
Does the Supabase security advisor catch these?
It flags tables with RLS off and some risky patterns. It cannot tell whether a policy matches your business rules.
Can my AI tool write the policies?
Yes, if you describe the rules precisely. Then test them with two accounts.