Guides

Supabase "new row violates row-level security policy": fix it without opening your table

By Pritesh Ghodge, security engineer · Last updated 5 November 2026

You click save in your Lovable, Bolt or Cursor app and get this back from Supabase:

new row violates row-level security policy for table "todos"

That's Row Level Security doing its job. RLS is on for the table, and the row you tried to write didn't pass a policy. The error itself is safe. The danger is the fix: ask an AI assistant to "make the error go away" and the quickest answers are with check (true) or turning RLS off. Both make the error disappear, and both let users write rows they shouldn't.

This guide shows how to find which check failed and fix it so each user can only write their own rows.

USING vs WITH CHECK in 30 seconds

A Postgres policy has two expressions. From the Postgres CREATE POLICY docs and Supabase's RLS guide:

• USING filters existing rows: what SELECT can see and which rows UPDATE and DELETE can touch. Rows that fail are silently skipped, no error.
• WITH CHECK checks new rows: what INSERT can add and what a row may look like after UPDATE. Rows that fail raise "new row violates row-level security policy".
• INSERT policies only have WITH CHECK. SELECT and DELETE only have USING. UPDATE and FOR ALL can have both, and if WITH CHECK is missing, Postgres uses the USING expression for new rows too.
• With RLS on and no policy for an operation, the answer is no. Permissive policies are ORed, so one loose policy opens the table even if the others are strict.

Step 1: see the policies on that table

In the Supabase SQL editor (replace todos with your table):

select policyname, cmd, roles, qual as using_expr, with_check
from pg_policies
where schemaname = 'public' and tablename = 'todos'
order by cmd;

Then match your situation below.

Cause 1: there's no INSERT policy

RLS is on, there's a SELECT policy, but nothing with cmd = INSERT or ALL. Default deny, so every insert fails. Add an owner-scoped one:

create policy "users insert own todos"
on public.todos for insert
to authenticated
with check ((select auth.uid()) = user_id);

That lets a signed-in user add rows, but only rows whose user_id is their own id.

Cause 2: user_id doesn't match auth.uid() (often it's null)

The policy is right, but the row isn't. Usual reasons:

• The app doesn't send user_id. The column ends up null, and auth.uid() = null is never true. Let the database fill it in:

  alter table public.todos
    alter column user_id set default auth.uid();

• The user isn't signed in when the insert runs. Without a session the request runs as anon and auth.uid() is null. Common after a page reload before the session is restored, or when the insert runs on a server that only has the anon key and doesn't pass the user's access token.
• The app sends a different id, like a profile id or an id from your own users table instead of the Supabase Auth user id.
• The policy targets the wrong role, e.g. to anon while the user is signed in (signed-in requests use authenticated).

Cause 3: insert().select() or upsert() needs more than an INSERT policy

supabase-js .insert(row).select() asks Postgres to return the new row. Postgres then checks the new row against your SELECT policies too, and errors if it fails. Fix: add an owner-scoped SELECT policy, or drop .select() if you don't need the row back.

.upsert() becomes insert ... on conflict do update, which checks INSERT, SELECT and UPDATE policies. It needs all three, scoped to the owner:

create policy "users read own todos"
on public.todos for select to authenticated
using ((select auth.uid()) = user_id);

create policy "users update own todos"
on public.todos for update to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);

Supabase's docs also note that an UPDATE needs a matching SELECT policy to work as expected.

Cause 4: an update tries to change the owner

If the error comes on UPDATE, the new version of the row failed WITH CHECK. Often the app sends the whole object back, including a user_id it shouldn't be changing, or a team/owner column that moved. That's the policy correctly stopping a row from being handed to someone else. Send only the fields that changed.

Cause 5: Supabase Storage uploads

Uploading a file inserts a row into storage.objects, so the same error means the bucket has no matching INSERT policy for that user. Upserting a file (upsert: true) also needs SELECT and UPDATE. Scope the policy to the bucket and the user's own folder:

create policy "users upload to own folder"
on storage.objects for insert to authenticated
with check (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.uid())::text
);

The storage bucket guide covers private buckets, listing and signed URLs.

Reproduce it in SQL as the real user

The SQL editor runs as postgres, which bypasses RLS, so "it works in SQL" proves nothing. Run the insert as a signed-in user inside a transaction that rolls back:

begin;
set local role authenticated;
set local request.jwt.claim.sub = 'PASTE-A-REAL-USER-UUID';
insert into public.todos (title, user_id)
values ('test', 'PASTE-A-REAL-USER-UUID');
rollback;

If that passes, try it with a different user's id in user_id. It should fail. If it doesn't, your policy lets users create rows for each other.

The two fixes that make it worse

• with check (true). The error goes away because every new row passes. On a table of user-owned rows, any signed-in user can now insert rows with someone else's user_id. If the policy is to public or to anon, anyone with your public key can, no account needed. And if open sign-ups are on, "signed in" means any stranger who makes an account.
• Turning RLS off, or swapping in the service_role key. With RLS off, the table grants are the only gate, and on many projects anon and authenticated have every privilege by default, so anyone with your public key can read and rewrite the whole table. The service_role key bypasses RLS completely and must never ship to a browser (see service_role key exposed).

with check (true) is fine where anyone really may add any row, like a public waitlist or contact form. Even then, keep reads closed and consider a rate limit, because the public key lets anyone call it from a script.

A prompt for Lovable, Bolt or Cursor

I'm getting "new row violates row-level security policy" on <table>.
Don't disable RLS, don't use the service_role key in the frontend,
and don't use with check (true) or using (true).
1. Show me the current policies on this table (pg_policies).
2. Find which check fails: missing INSERT policy, user_id not set
   or not equal to auth.uid(), user not signed in, or .select()/upsert
   needing SELECT/UPDATE policies.
3. Fix it with owner-scoped policies TO authenticated using
   (select auth.uid()) = user_id, and set user_id default auth.uid()
   if the app doesn't send it.
Show me the SQL before applying it.

What an outside scan can and can't see

From outside, a scanner can see your live JavaScript and whether a table is readable with your public key. It can't see your policies and shouldn't test writes against a live app. That's why write problems like with check (true) need the policy checker or the SQL test above, and a two-account test: sign in as user B and try to create or change a row that belongs to user A.

Keep it that way

Policies get loosened in the middle of a late-night "fix this error" session and nobody notices until the data is somewhere it shouldn't be. Abbi Labs scans your live app for leaked keys, Supabase tables readable with your public key, exposed .env/.git files and security headers. Monitor re-scans weekly and after every deploy, and emails you only when something new appears.

Run a free scan

FAQ

Related guides

• Free tool: Supabase RLS policy checker
• Supabase WITH CHECK (true): what that INSERT policy actually opens
• Supabase "42501 permission denied for table": fix it with a GRANT, not by turning off RLS
• How to check if your Supabase tables are readable by anyone
• Is your Supabase anon key safe to expose?
• Is your Supabase storage bucket public?
• Lovable app security checklist