Fixing "new row violates row-level security policy" in Supabase

Ahmed Hassan Yaseen — Sun, 18 Oct 2026 06:35:18 +0000

If your app shows "new row violates row-level security policy for table" (Postgres code 42501), the short answer:

Postgres refused the row because no policy's WITH CHECK allows it for the role making the request. Add an INSERT policy (and UPDATE plus SELECT policies for upserts) that matches how your app writes, for the authenticated role, and make sure the user is actually signed in.

This comes up constantly in apps built with AI builders like Lovable and Bolt, because they often create a read policy and forget the write side. Below: how to tell which case you are in, the policies that fix it, and how to prove the fix with a test, following the Supabase row-level security guide.

Why it happens

There is no INSERT policy. With row-level security on and no INSERT policy, every insert fails. AI builders often create a SELECT policy and forget the write side.
The policy compares the wrong column. The check reads (select auth.uid()) = user_id, but the app inserts the row without user_id, or with a different column such as owner_id or created_by.
The request is not signed in. For a request without a session, auth.uid() is null, so auth.uid() = user_id is never true. A page that loads before the session is restored writes as anon.
An upsert needs more than INSERT. An upsert may update an existing row, which needs an UPDATE policy with both USING and WITH CHECK, and a SELECT policy so the row can be found.
The role is missing a grant. A missing table grant raises the same code 42501 before any policy runs.

Find the cause in five minutes

Open the browser console, run the action again and copy the full error, including the table name.
In the Supabase dashboard, open Authentication > Policies and list the policies on that table, per operation.
Log the session just before the write: if supabase.auth.getSession() returns no session, the request runs as anon.
Compare the columns the app sends with the columns the policy reads. A missing user_id is the most common mismatch.
If the app uses upsert, check for UPDATE and SELECT policies as well as INSERT.

The fixes

Add an INSERT policy for signed-in users that owns the row

Make sure the table has a user_id column that references auth.users.
Create the policy for the authenticated role only.
Send user_id with every insert, or give the column a default of auth.uid().

alter table public.projects enable row level security;

create policy "Users can create their own projects"
on public.projects for insert
to authenticated
with check ( (select auth.uid()) = user_id );

-- Optional: fill user_id on the server so the app cannot forget it
alter table public.projects alter column user_id set default auth.uid();

Cover upserts and updates

Add a SELECT policy so the existing row can be found.
Add an UPDATE policy with USING (which rows may change) and WITH CHECK (what they may become).

create policy "Users can read their own projects"
on public.projects for select
to authenticated
using ( (select auth.uid()) = user_id );

create policy "Users can update their own projects"
on public.projects for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

Wait for the session before writing

Write only after the auth state is known; disable the save button until a user exists.
Never fix this by switching the write to a secret or service_role key in the browser: that bypasses every policy for everyone.

Test the policies in SQL before you ship

In the SQL editor (or a pgTAP test), switch to the role and the user inside a transaction, as the Supabase guide recommends.
Try the write as the owner, as another user and as anon, and expect 42501 for the last two.
Keep it as a test: supabase test new projects_rls.test, then run supabase test db before every release. Prove an allowed write by checking the row exists afterwards, not only that no error was raised.

-- Owner: must succeed
begin;
set local role authenticated;
set local request.jwt.claim.sub = '11111111-1111-1111-1111-111111111111';
insert into public.projects (name, user_id)
values ('My project', '11111111-1111-1111-1111-111111111111');
rollback;

-- Same user writing a row for someone else: must fail with 42501
begin;
set local role authenticated;
set local request.jwt.claim.sub = '11111111-1111-1111-1111-111111111111';
insert into public.projects (name, user_id)
values ('Not mine', '22222222-2222-2222-2222-222222222222');
rollback;

Check that it is really fixed

Signed in as user A, insert a row: it succeeds.
Signed in as user A, try to insert a row with user B's user_id: it must fail with 42501.
Signed out, try the same insert: it must fail.
Run the Supabase security advisor (Database > Advisors) and confirm the table shows no warnings.

Keep it from coming back

Write one policy per operation and name the role on each (to authenticated).
Keep a short test per table: owner can write, other user cannot, anonymous cannot.
Index the column your policies filter on (user_id) so policies stay fast as data grows.
Write (select auth.uid()) rather than auth.uid(): Postgres then runs it once per statement instead of once per row, which matters on large tables.

Originally published in the StacksMesh fix library, which covers the errors AI-built apps hit most, each checked against the official docs. To check a live app for exposed keys and missing headers, the Launch Check is free and needs no sign-up. I work at StacksMesh.

Sources: Supabase: Row Level Security, Supabase: API keys.

DEV Community: Ahmed Hassan Yaseen