Supabase 42501 permission denied: en rettighed, ikke RLS

Jeg har bygget et gratis Supabase sikkerhedstjek, der læser rettigheder på hver eksponeret tabel, og 42501 er den fejl, folk rammer, når rettighederne er forkerte i den modsatte retning: for få i stedet for for mange. Her er, hvad den betyder, og hvad jeg så, da jeg genskabte den.

Hvad betyder fejlen 42501 i Supabase?

42501 er Postgres’ kode for utilstrækkelig rettighed. Postgres tjekker to lag, før en klient rører en tabel: rettigheder afgør, om rollen overhovedet må udføre operationen, og RLS-policies afgør, hvilke rækker. En manglende rettighed fejler først, som en fejl. En policy, der ikke matcher noget, fejler lydløst, som en tom liste. Så når du ser 42501, så kig på rettighederne, ikke på dine policies.

PostgREST, Data API’et bag supabase-js, sender fejlen videre med et hint. På min lokale stack (Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14) gav en anmodning med publishable key mod en tabel uden rettighed til anon 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 efter 30. oktober 2026?

Indtil nu fik en ny tabel i public select, insert, update og delete til anon, authenticated og service_role gennem standardrettigheder, så den kunne nås via Data API’et i samme øjeblik, den blev oprettet, beskyttet eller ej. Supabases changelog fjerner de standarder: valgfrit fra 28. april 2026, standard for nye projekter fra 30. maj 2026 og anvendt på alle eksisterende projekter 30. oktober 2026. Eksisterende tabeller beholder deres rettigheder.

Hvad skiftet ellers ødelægger, og hvordan du tjekker dit projekt før: Supabase 30. oktober: hvad knækker, og hvordan tjekker du.

Jeg anvendte den samme ændring på mit lokale projekt med de to alter default privileges … revoke-sætninger fra changeloggen og oprettede derefter en ny tabel invoices:

Anmodning til den nye tabel	Resultat
Publishable key, ingen rettighed	HTTP 401, 42501, hint GRANT SELECT ON public.invoices TO anon;
Secret key, ingen rettighed	HTTP 403, 42501, hint … TO service_role;
Publishable key, efter grant select og enable row level security	HTTP 200, [], indtil en policy tillader rækker

To ting overraskede mig. Secret key afvises også: service_role omgår RLS, men har stadig brug for en rettighed, så en Edge Function eller et serverjob, der skriver til en ny tabel, går i stykker på samme måde. Og revoke tager kun de fire operationer tilbage: den nye tabel kom stadig med REFERENCES, TRIGGER og TRUNCATE til anon, authenticated og service_role. Ingen policy gælder for TRUNCATE.

Hvordan retter du 42501 uden at åbne tabellen?

Behandl rettighed, RLS og policy som én ændring i én migrering, og giv hver rolle kun det, den har brug for:

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);

Det indledende revoke all rydder de TRUNCATE, TRIGGER og REFERENCES, der fulgte med tabellen. Svar ikke på 42501 med grant all on all tables in schema public to anon: det er den gamle standard tilbage, for alle tabeller på én gang, og hver tabel uden RLS bliver læsbar for alle med din offentlige nøgle.

Hvis et AI-værktøj opretter dine tabeller, så fortæl det, at det skal udsende rettigheder, RLS og policies i den samme migrering. Hintet i fejlen er skrevet, så en agent kan rette rettigheden selv, men hintet nævner kun rettigheden, ikke den RLS, der bør følge med.

Hvordan ser tjekket det?

Fire af dets regler læser rettighedslaget: “Standardrettigheder, der åbner nye objekter for API’et” markerer projekter, der stadig automatisk giver nye tabeller rettigheder, “Ubrugte skriverettigheder til anonyme besøgende” finder skriverettigheder til anon, som ingen policy bruger, og “Unødvendige tabelrettigheder for indloggede brugere” finder TRUNCATE, TRIGGER og REFERENCES som dem ovenfor. “Politikker, der aldrig kører: rollen har ingen grant” viser tabeller, hvor en policy nævner en rolle, der ikke har nogen grant til den kommando, og sådan ser en ny tabel ud efter 30. oktober. Hvorfor RLS stadig har betydning efter rettigheden, står i sådan tester du Supabase RLS, og hvordan rettigheder og policies ser ud på tværs af en hel app, står i min sikkerhedstjekliste til Lovable-apps.