RLS bloqueando INSERT mesmo com policy WITH CHECK (true) e current_user = anon

[atelierterraeluz]

[GaryAustin1]

Not much info.
But I'm going to guess you are doing a REST insert and it either has a .select(), .single() or is a library that automatically returns data. If so you also have to meet a SELECT USING policy.

[placements-microdegree]

A permissive WITH CHECK (true) on INSERT usually is not the whole story — a few things commonly still block anon inserts even when that clause looks correct.

1. RLS is enabled but you only fixed INSERT

If SELECT (or UPDATE) policies are missing, inserts can succeed server-side yet the client .select() after insert fails — which looks like "INSERT blocked". Check policies for all commands you use in the same request.

2. INSERT policy role target

Policies apply to roles listed in the policy (TO authenticated, TO anon, or TO public). Confirm the policy is for anon (or public) if you call PostgREST with the anon key and no user JWT.

Run in SQL Editor (as a sanity check):

select polname, polcmd, polroles::regrole[], qual, with_check
from pg_policy p
join pg_class c on c.oid = p.polrelid
where c.relname = 'your_table';

3. current_user = anon in SQL Editor is misleading

The SQL Editor runs as postgres, not anon. To reproduce client behavior use:

set role anon;
set request.jwt.claim.sub = '<uuid-if-authenticated>';
-- then try insert

Or test via REST with the anon key only.

4. Column-level GRANTs

RLS can pass while table/column privileges still deny the insert:

grant insert on public.your_table to anon;

(Adjust schema/table.)

5. Missing WITH CHECK on UPDATE (different symptom)

For INSERT, Postgres requires a passing WITH CHECK expression. If you copied a USING-only policy pattern from a SELECT policy, INSERT will fail even when SELECT works.

6. Check the exact PostgREST error code

• 42501 → permission denied (RLS or GRANT)
• 23505 → unique violation (not RLS)

Paste the full JSON error from the client (code, message, details, hint) — that usually pinpoints whether it's RLS vs grant vs constraint.

---

I maintain RLS Inspector, a small client-side tool that lists policies from pg_policies and flags missing WITH CHECK, overly-permissive USING (true), and missing SELECT coverage — useful when you have many tables.

If you share your table name + create policy statements (redact columns), happy to point at the exact mismatch.

[cekuu35]

Complementando as duas respostas acima — two things that can still block an INSERT even when the WITH CHECK (true) policy and the role target both look correct:

1. A restrictive policy elsewhere on the same table. Permissive policies are OR'ed together, but any policy created AS RESTRICTIVE is AND'ed on top of them — a single restrictive policy blocks anon even though your permissive WITH CHECK (true) passes. Check with:

select polname, polcmd, polpermissive,
       pg_get_expr(polwithcheck, polrelid) as with_check
from pg_policy
where polrelid = 'public.your_table'::regclass;

Rows with polpermissive = f are the suspects.

2. The violation may be coming from a different table, via a trigger. The error text names the table it failed on: new row violates row-level security policy for table "…". If the table in that message is not the one you inserted into, a BEFORE/AFTER trigger is writing to another RLS-enabled table where anon has no INSERT policy (audit/log tables are the usual case).

If neither turns anything up, post the exact error line plus the output of select * from pg_policies where tablename = 'your_table'; — with those two it is usually a one-look diagnosis.

(For reproducing this class of failure locally: I keep a runnable two-role isolation fixture at cekuu35/supabase-rls-leak-demo — the same test suite goes red on the broken branch and green on the fixed one, no cloud project needed.)