Authenticated INSERT always rejected by RLS, even with with check (true)

[goanlife]

Summary

Any INSERT performed by the authenticated role through PostgREST (POST /rest/v1/<table>) is rejected with:

42501: new row violates row-level security policy for table "<table>"

This happens even when the table's only INSERT policy is with check (true) (unconditionally true), which should never reject a row under normal PostgreSQL RLS semantics. SELECT/UPDATE-style read access and the underlying auth/JWT pipeline all work correctly - only the INSERT WITH CHECK enforcement appears broken.

Environment

• Affected projects: ahkhicstbqhfqtljxlpz (original project) and hgbawrheilblucsswpzc (brand-new project, brand-new organization, created specifically to rule out a per-project issue)
• Postgres version: PostgreSQL 17.6 on x86_64-pc-linux-gnu (from select version())
• Region: eu-west-1 (Ireland)
• Reproduced with both the new publishable key (sb_publishable_...) and the legacy anon key (HS256 JWT) - same failure with both
• Reproduced via raw fetch() calls to the REST API with a real password-grant access token (not through the SQL editor, to rule out editor-specific artifacts)

Minimal reproduction

create table public.repro (
  id uuid primary key default gen_random_uuid(),
  owner_id uuid not null
);
alter table public.repro enable row level security;
create policy "always_allow" on public.repro for insert with check (true);
notify pgrst, 'reload schema';

Then, authenticated as a real confirmed user (password sign-in, valid JWT verified via auth.uid()/auth.jwt()):

const authRes = await fetch(`${SUPABASE_URL}/auth/v1/token?grant_type=password`, {
  method: 'POST',
  headers: { apikey: ANON_KEY, 'Content-Type': 'application/json' },
  body: JSON.stringify({ email, password }),
});
const { access_token, user } = await authRes.json();

const res = await fetch(`${SUPABASE_URL}/rest/v1/repro`, {
  method: 'POST',
  headers: {
    apikey: ANON_KEY,
    Authorization: `Bearer ${access_token}`,
    'Content-Type': 'application/json',
    Prefer: 'return=representation',
  },
  body: JSON.stringify({ owner_id: user.id }),
});
// res.status === 403
// body: {"code":"42501","details":null,"hint":null,"message":"new row violates row-level security policy for table \"repro\""}

Expected: insert succeeds (HTTP 201), since the policy is with check (true).
Actual: HTTP 403, 42501, RLS violation, on every attempt.

What we've already ruled out

• Not a GRANT/privilege issue - has_table_privilege('authenticated', 'public.<table>', 'INSERT') returns true.
• Not row_security being off - current_setting('row_security') returns on.
• Not a bad JWT / auth context - verified via a security invoker debug function that returns auth.uid(), auth.role(), and current_setting('request.jwt.claims', true) in the same request/transaction as the failing insert: all values are correct (role = authenticated, uid matches the row's owner_id).
• Not specific to auth.uid() - tried owner_id = auth.uid(), owner_id = (select auth.uid()), owner_id::text = (auth.jwt() ->> 'sub'), and finally with check (true). All fail identically.
• Not caused by BEFORE INSERT/UPDATE triggers we added - reproduces on a table with zero triggers.
• Not a stuck PostgREST/connection-pool cache - reproduces immediately after a full project restart (Settings -> General -> Restart project) on the original project.
• Not project-specific - reproduces identically on a second, brand-new project in a brand-new organization, created purely to test this.
• Not API-key-format-specific - reproduces with both the new sb_publishable_... key and the legacy HS256 anon JWT key.

Question

Given the above, this looks like a platform-level regression in PostgREST's RLS enforcement for INSERT (possibly tied to the PostgreSQL 17.6 rollout, since that's the one constant across both affected projects), rather than anything in our schema/policies/grants. Is this a known issue, and is there a workaround in the meantime? Happy to share direct project access / logs if useful.

Project refs: ahkhicstbqhfqtljxlpz, hgbawrheilblucsswpzc.

[GaryAustin1]

You need to have a Select policy as you are returning data from the insert.

[goanlife]

That was it, thank you! Confirmed: adding a SELECT policy that covers the row at insert-time fixed it immediately.

For anyone finding this later: our INSERT policy was fine, but our SELECT policy depended on a row inserted by an AFTER INSERT trigger on a related table, which isn't visible yet when the RETURNING clause's implicit SELECT check runs. Fixed by broadening the SELECT policy to also allow owner_id = auth.uid().

Sorry for the noise, and thanks again for the quick pointer!