Supabase 42501 permission denied: en tilgang, ikke RLS

Jeg har bygget en gratis Supabase-sikkerhetssjekk som leser tilgangene på hver eksponerte tabell, og 42501 er feilen folk møter når tilgangene er feil i den andre retningen: for få i stedet for for mange. Her er hva den betyr og hva jeg så da jeg reproduserte den.

Hva betyr feilen 42501 i Supabase?

42501 er Postgres-koden for utilstrekkelig rettighet. Postgres sjekker to lag før en klient rører en tabell: tilganger avgjør om rollen i det hele tatt kan kjøre operasjonen, og RLS-policyer avgjør hvilke rader. En manglende tilgang feiler først, som en feil. En policy som ikke treffer noe, feiler stille, som en tom liste. Så når du ser 42501, se på tilganger, ikke på policyene dine.

PostgREST, Data API-et bak supabase-js, sender feilen videre med et hint. På den lokale stacken min (Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14) svarte en forespørsel med publishable key mot en tabell uten tilgang for anon med HTTP 401 og:

{
  "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"
}

Hvorfor får nye tabeller 42501 etter 30. oktober 2026?

Til nå fikk en ny tabell i public select, insert, update og delete for anon, authenticated og service_role gjennom standardrettigheter, så den kunne nås over Data API-et i det øyeblikket den ble opprettet, beskyttet eller ikke. Supabases changelog fjerner disse standardene: valgfritt fra 28. april 2026, standard for nye prosjekter fra 30. mai 2026, og innført for alle eksisterende prosjekter 30. oktober 2026. Eksisterende tabeller beholder tilgangene sine.

Hva mer omleggingen knekker, og hvordan du sjekker prosjektet på forhånd: Supabase 30. oktober: hva som knekker og hvordan sjekke.

Jeg brukte den samme endringen på det lokale prosjektet mitt med de to alter default privileges … revoke-setningene fra changeloggen, og opprettet så en ny tabell invoices:

Forespørsel mot den nye tabellen	Resultat
Publishable key, ingen tilgang	HTTP 401, 42501, hint GRANT SELECT ON public.invoices TO anon;
Secret key, ingen tilgang	HTTP 403, 42501, hint … TO service_role;
Publishable key, etter grant select og enable row level security	HTTP 200, [] til en policy slipper inn rader

To ting overrasket meg. Secret key nektes også: service_role omgår RLS, men trenger likevel en tilgang, så en Edge Function eller en serverjobb som skriver til en ny tabell går i stykker på samme måte. Og revoke tar bare tilbake de fire operasjonene: den nye tabellen kom fortsatt med REFERENCES, TRIGGER og TRUNCATE for anon, authenticated og service_role. Ingen policy gjelder for TRUNCATE.

Hvordan fikser du 42501 uten å åpne tabellen?

Behandle tilgangen, RLS og policyen som én endring, i én migrasjon, og gi hver rolle bare det den trenger:

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 fjerner TRUNCATE, TRIGGER og REFERENCES som fulgte med tabellen. Svar ikke på 42501 med grant all on all tables in schema public to anon: det er den gamle standarden tilbake, for alle tabeller på én gang, og hver tabell uten RLS blir lesbar for alle med den offentlige nøkkelen din.

Hvis et AI-verktøy oppretter tabellene dine, be det lage tilganger, RLS og policyer i samme migrasjon. Hintet i feilen er skrevet slik at en agent kan fikse tilgangen selv, men hintet nevner bare tilgangen, ikke RLS-en som bør følge med.

Hvordan ser sjekken dette?

Fire av reglene leser tilgangslaget: “Standardrettigheter som åpner nye objekter for API-et” flagger prosjekter som fortsatt gir nye tabeller tilgang automatisk, “Ubrukte skriverettigheter for anonyme besøkende” finner skrivetilganger for anon som ingen policy bruker, og “Unødvendige tabellrettigheter for innloggede brukere” finner TRUNCATE, TRIGGER og REFERENCES som de over. “Policyer som aldri kjører: rollen mangler tilgang” lister tabeller der en policy navngir en rolle som ikke har tilgang til den kommandoen, og slik ser en ny tabell ut etter 30. oktober. Hvorfor RLS fortsatt betyr noe etter at tilgangen er gitt, står i hvordan du tester Supabase RLS, og hvordan tilganger og policyer ser ut i en hel app, står i sikkerhetsjekklisten min for Lovable-apper.