By Partly fixable yourself. One policy in the Supabase dashboard, if you know the table.
What you see. Saving a form fails with new row violates row-level security policy, or code 42501, while reading data still works.
Why it happens
Row Level Security is doing its job. Once RLS is enabled, Supabase blocks every read and write through the publishable key until a policy allows it. Reads often work because the agent added a select policy and stopped. Inserts need their own policy with a WITH CHECK clause, which decides what the new row is allowed to look like. Supabase says a missing grant or a WITH CHECK violation both raise error code 42501.
Common reasons the check fails: the row's user_id does not equal auth.uid() because the form never fills it in, the user is not signed in so auth.uid() is null, or the policy is scoped to the authenticated role while the app calls as anon. Lovable and Bolt both generate these policies with the AI, so one table has them and the next does not. Do not fix this by turning RLS off, and never by moving the secret key into the app.
Fix it yourself
- Read the full error in the browser console or the Supabase Logs page. It names the table.
- In Supabase, open Table Editor, select that table, and open its policies. Look for one whose command is INSERT.
- If none exists, add one for the
authenticatedrole withwith check ((select auth.uid()) = user_id), using your real owner column name. - If one exists, check the form sends
user_idset to the current user, and that the user is signed in when it runs. A nullauth.uid()fails silently. - Ask the agent to write matching select, insert, update, and delete policies for every table that stores user data, then test with two accounts.
When to get an engineer
Stop if the error appears on many tables, if fixing one policy breaks another, or if the app uses the secret key in edge functions to get around RLS. Tell the engineer the table names, the error text, and who should be allowed to write what. A single fix is €99–$990 within 1–2 days. A review of the policies on every table is a one-off check at $49–$800, and it is worth doing before launch.
Top-rated companies for Supabase apps
Ranked by our score: published prices, scope of work, AI tools named, timing and a low-risk first step. How we score.
- 1Redlab10.0/10Best for: A full rescue by one team that keeps buildingFree first step · from $490
- 2Vibe Code Rescue (Lev Arakelyan)9.0/10Best for: A one-off check and a cleanupFrom $299
- 3LazyCodeLab9.0/10Best for: A one-off check and a cleanupFrom $399
Check these
Access rules are on for every table
In Supabase, open Table Editor: every table should show RLS enabled, with at least one policy. In Firebase, your rules should never say allow read, write: if true.
One user cannot open another user's records
Sign in as user A, copy a request from the Network tab, and change the record ID to one that belongs to user B. You should get an error or an empty result.
Input is validated on the server
Forms that only check input in the browser accept anything sent directly to the API.
Questions
Can I just disable RLS on that table?
No. Without RLS anyone holding your public key can read and change every row in the table. Add the missing insert policy instead. It takes a few minutes.
Why does the agent keep writing policies with using (true)?
Because that makes the error go away fastest. It also makes the table public. Ask for policies that compare (select auth.uid()) to the owner column, and check each one yourself.
Sources: Supabase: Row Level Security; Supabase: RLS performance and best practices; Lovable: Supabase integration.