Supabase 42501 permission denied: en behörighet, inte RLS

Jag har byggt en gratis Supabase-säkerhetskontroll som läser behörigheterna på varje exponerad tabell, och 42501 är felet folk möter när behörigheterna är fel åt andra hållet: för få i stället för för många. Här är vad det betyder och vad jag såg när jag återskapade det.

Vad betyder felet 42501 i Supabase?

42501 är Postgres-koden för otillräcklig behörighet. Postgres kontrollerar två lager innan en klient rör en tabell: behörigheter avgör om rollen över huvud taget får köra operationen, och RLS-policyer avgör vilka rader. En saknad behörighet misslyckas först, som ett fel. En policy som inte matchar något misslyckas tyst, som en tom lista. Så när du ser 42501, titta på behörigheter, inte på dina policyer.

PostgREST, Data API:et bakom supabase-js, skickar felet vidare med en ledtråd. På min lokala stack (Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14) svarade en förfrågan med publishable key mot en tabell utan behörighet för anon med HTTP 401 och:

{
  "code": "42501",
  "details": null,
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.orders TO anon;",
  "message": "permission denied for table orders"
}

Varför får nya tabeller 42501 efter 30 oktober 2026?

Hittills fick en ny tabell i public select, insert, update och delete för anon, authenticated och service_role genom standardbehörigheter, så den gick att nå över Data API:et i samma ögonblick den skapades, skyddad eller inte. Supabases changelog tar bort de standardvärdena: valfritt från 28 april 2026, standard för nya projekt från 30 maj 2026 och tillämpat på alla befintliga projekt den 30 oktober 2026. Befintliga tabeller behåller sina behörigheter.

Vad mer omställningen förstör och hur du kollar projektet i förväg: Supabase 30 oktober: vad som går sönder och hur du kollar.

Jag tillämpade samma ändring på mitt lokala projekt med de två alter default privileges … revoke-satserna från changeloggen och skapade sedan en ny tabell invoices:

Förfrågan mot den nya tabellen	Resultat
Publishable key, ingen behörighet	HTTP 401, 42501, ledtråd GRANT SELECT ON public.invoices TO anon;
Secret key, ingen behörighet	HTTP 403, 42501, ledtråd … TO service_role;
Publishable key, efter grant select och enable row level security	HTTP 200, [] tills en policy släpper in rader

Två saker överraskade mig. Secret key nekas också: service_role kringgår RLS men behöver ändå en behörighet, så en Edge Function eller ett serverjobb som skriver till en ny tabell går sönder på samma sätt. Och revoke tar bara tillbaka de fyra operationerna: den nya tabellen kom fortfarande med REFERENCES, TRIGGER och TRUNCATE för anon, authenticated och service_role. Ingen policy gäller för TRUNCATE.

Hur fixar du 42501 utan att öppna tabellen?

Behandla behörigheten, RLS och policyn som en ändring, i en migrering, och ge varje roll bara det den behöver:

revoke all on table public.invoices from anon, authenticated;
grant select, insert, update on table public.invoices to authenticated;
grant select, insert, update, delete on table public.invoices to service_role;

alter table public.invoices enable row level security;

create policy "Owners read their invoices"
on public.invoices for select
to authenticated
using ((select auth.uid()) = user_id);

revoke all först rensar bort TRUNCATE, TRIGGER och REFERENCES som följde med tabellen. Svara inte på 42501 med grant all on all tables in schema public to anon: det är den gamla standarden tillbaka, för alla tabeller på en gång, och varje tabell utan RLS blir läsbar för alla med din publika nyckel.

Om ett AI-verktyg skapar dina tabeller, be det skriva behörigheter, RLS och policyer i samma migrering. Ledtråden i felet är skriven så att en agent kan fixa behörigheten själv, men ledtråden nämner bara behörigheten, inte den RLS som bör följa med.

Hur ser kontrollen detta?

Fyra av dess regler läser behörighetslagret: “Standardbehörigheter som öppnar nya objekt för API:t” flaggar projekt som fortfarande ger nya tabeller behörighet automatiskt, “Oanvända skrivbehörigheter för anonyma besökare” hittar skrivbehörigheter för anon som ingen policy använder, och “Onödiga tabellbehörigheter för inloggade användare” hittar TRUNCATE, TRIGGER och REFERENCES som de ovan. “Policyer som aldrig körs: rollen saknar behörighet” listar tabeller där en policy nämner en roll som saknar behörighet för det kommandot, vilket är så en ny tabell ser ut efter 30 oktober. Varför RLS fortfarande spelar roll efter att behörigheten getts finns i hur du testar Supabase RLS, och hur behörigheter och policyer ser ut i en hel app finns i min säkerhetschecklista för Lovable-appar.