Error library · Supabase refuses a save
new row violates row-level security policy (Supabase)
Your database refused something the app tried to do on the "orders" table. Supabase has rules about who may read or change which rows (called row-level security), and those rules don't allow this request — so the app asks, the database says no, and the action fails.
Who it affects
Signed-in people trying this action see it fail — 5 sessions so far. Usually a save, a new record or an update that never goes through.
Numbers here are from an example app where 5 visitors hit it. How serious: High — an important part of the app is broken for some people.
How to fix it
Give this to the AI that builds your app. It’s the prompt Vigilia writes for this error — shown here for an example app (an orders table, a /checkout page); for your app, Vigilia fills in the real details from what your visitors hit.
For Lovable
Lovable manages your Supabase project, so it can make this change. Bug: Supabase rejects a request from a signed-in user on the "orders" table because no row-level security policy allows it.
Evidence: "new row violates row-level security policy for table "orders"" — seen 12 times across ~5 sessions, on /checkout.
What to change:
1. Look at the row-level security policies for "orders" and at the exact operation the app performs there (select, insert, update or delete).
2. Add or fix the policy so the intended users can do exactly that — typically only on their own rows, e.g. a check that the row's owner column equals auth.uid().
3. Keep row-level security ON. Do not disable it, do not write a policy that allows everyone, and never put the service_role key in the browser to get around it.
4. Make the app show a clear message if the database refuses a request, instead of failing silently.
Acceptance criteria: signed in as a normal user, the action succeeds for their own data and is still refused for someone else's. No more 403 from /rest/v1/orders.For Bolt
Bolt manages your Supabase project, so it can make this change. Bug: Supabase rejects a request from a signed-in user on the "orders" table because no row-level security policy allows it.
Evidence: "new row violates row-level security policy for table "orders"" — seen 12 times across ~5 sessions, on /checkout.
What to change:
1. Look at the row-level security policies for "orders" and at the exact operation the app performs there (select, insert, update or delete).
2. Add or fix the policy so the intended users can do exactly that — typically only on their own rows, e.g. a check that the row's owner column equals auth.uid().
3. Keep row-level security ON. Do not disable it, do not write a policy that allows everyone, and never put the service_role key in the browser to get around it.
4. Make the app show a clear message if the database refuses a request, instead of failing silently.
Acceptance criteria: signed in as a normal user, the action succeeds for their own data and is still refused for someone else's. No more 403 from /rest/v1/orders.For Cursor
Bug: Supabase rejects a request from a signed-in user on the "orders" table because no row-level security policy allows it.
Evidence: "new row violates row-level security policy for table "orders"" — seen 12 times across ~5 sessions, on /checkout.
What to change:
1. Look at the row-level security policies for "orders" and at the exact operation the app performs there (select, insert, update or delete).
2. Add or fix the policy so the intended users can do exactly that — typically only on their own rows, e.g. a check that the row's owner column equals auth.uid().
3. Keep row-level security ON. Do not disable it, do not write a policy that allows everyone, and never put the service_role key in the browser to get around it.
4. Make the app show a clear message if the database refuses a request, instead of failing silently.
Acceptance criteria: signed in as a normal user, the action succeeds for their own data and is still refused for someone else's. No more 403 from /rest/v1/orders.For Claude Code
Bug: Supabase rejects a request from a signed-in user on the "orders" table because no row-level security policy allows it.
Evidence: "new row violates row-level security policy for table "orders"" — seen 12 times across ~5 sessions, on /checkout.
What to change:
1. Look at the row-level security policies for "orders" and at the exact operation the app performs there (select, insert, update or delete).
2. Add or fix the policy so the intended users can do exactly that — typically only on their own rows, e.g. a check that the row's owner column equals auth.uid().
3. Keep row-level security ON. Do not disable it, do not write a policy that allows everyone, and never put the service_role key in the browser to get around it.
4. Make the app show a clear message if the database refuses a request, instead of failing silently.
Acceptance criteria: signed in as a normal user, the action succeeds for their own data and is still refused for someone else's. No more 403 from /rest/v1/orders.For any other tool
Bug: Supabase rejects a request from a signed-in user on the "orders" table because no row-level security policy allows it.
Evidence: "new row violates row-level security policy for table "orders"" — seen 12 times across ~5 sessions, on /checkout.
What to change:
1. Look at the row-level security policies for "orders" and at the exact operation the app performs there (select, insert, update or delete).
2. Add or fix the policy so the intended users can do exactly that — typically only on their own rows, e.g. a check that the row's owner column equals auth.uid().
3. Keep row-level security ON. Do not disable it, do not write a policy that allows everyone, and never put the service_role key in the browser to get around it.
4. Make the app show a clear message if the database refuses a request, instead of failing silently.
Acceptance criteria: signed in as a normal user, the action succeeds for their own data and is still refused for someone else's. No more 403 from /rest/v1/orders.Vigilia catches this automatically
When this happens on your live app, Vigilia recognises it at once — no waiting, no AI credits — tells you who it affects, hands your AI the fix, and confirms it held with real visitors.