Supabase 42501 permission denied: oikeus, ei RLS

Rakensin ilmaisen Supabase-tietoturvatarkistuksen, joka lukee jokaisen julkaistun taulun oikeudet, ja 42501 on virhe, johon ihmiset törmäävät, kun oikeudet ovat väärin toiseen suuntaan: liian vähän liian monen sijaan. Tässä on, mitä se tarkoittaa ja mitä näin, kun toistin sen.

Mitä virhe 42501 tarkoittaa Supabasessa?

42501 on Postgresin koodi riittämättömille oikeuksille. Postgres tarkistaa kaksi kerrosta ennen kuin asiakas koskee tauluun: oikeudet ratkaisevat, saako rooli ajaa operaation lainkaan, ja RLS-politiikat ratkaisevat, mihin riveihin. Puuttuva oikeus epäonnistuu ensin, virheenä. Politiikka, joka ei täsmää mihinkään, epäonnistuu hiljaa, tyhjänä listana. Kun siis näet 42501:n, katso oikeuksia, älä politiikkojasi.

PostgREST, supabase-js:n takana oleva Data API, välittää virheen eteenpäin vihjeen kanssa. Paikallisella stackillani (Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14) publishable keyllä tehty pyyntö taululle, jolla ei ollut oikeutta roolille anon, palautti HTTP 401:n ja:

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

Miksi uudet taulut saavat 42501:n 30. lokakuuta 2026 jälkeen?

Tähän asti uusi public-taulu sai select-, insert-, update- ja delete-oikeudet rooleille anon, authenticated ja service_role oletusoikeuksien kautta, joten se oli tavoitettavissa Data API:n kautta heti luomishetkellä, suojattuna tai ei. Supabasen changelog poistaa nuo oletukset: valinnaisena 28. huhtikuuta 2026 alkaen, uusien projektien oletuksena 30. toukokuuta 2026 alkaen ja kaikkiin olemassa oleviin projekteihin sovellettuna 30. lokakuuta 2026. Olemassa olevat taulut säilyttävät oikeutensa.

Mitä muuta vaihto rikkoo ja miten projektin voi tarkistaa etukäteen: Supabasen grant-muutos 30. lokakuuta: mikä hajoaa.

Sovelsin saman muutoksen paikalliseen projektiini kahdella changelogin alter default privileges … revoke -lauseella ja loin sitten uuden taulun invoices:

Pyyntö uuteen tauluun	Tulos
Publishable key, ei oikeutta	HTTP 401, 42501, vihje GRANT SELECT ON public.invoices TO anon;
Secret key, ei oikeutta	HTTP 403, 42501, vihje … TO service_role;
Publishable key, grant select- ja enable row level security -lauseiden jälkeen	HTTP 200, [], kunnes politiikka päästää rivejä

Kaksi asiaa yllätti minut. Secret keykin torjutaan: service_role ohittaa RLS:n, mutta tarvitsee silti oikeuden, joten Edge Function tai palvelintyö, joka kirjoittaa uuteen tauluun, hajoaa samalla tavalla. Ja revoke ottaa pois vain ne neljä operaatiota: uusi taulu tuli silti mukanaan REFERENCES-, TRIGGER- ja TRUNCATE-oikeuksilla rooleille anon, authenticated ja service_role. Mikään politiikka ei koske TRUNCATE-operaatiota.

Miten 42501 korjataan avaamatta taulua?

Käsittele oikeus, RLS ja politiikka yhtenä muutoksena, yhdessä migraatiossa, ja anna kullekin roolille vain se, mitä se tarvitsee:

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

Ensin ajettava revoke all poistaa taulun mukana tulleet TRUNCATE-, TRIGGER- ja REFERENCES-oikeudet. Älä vastaa 42501:een lauseella grant all on all tables in schema public to anon: se on vanha oletus takaisin, kaikille tauluille kerralla, ja jokainen taulu ilman RLS:ää muuttuu luettavaksi kenelle tahansa, jolla on julkinen avaimesi.

Jos tekoälytyökalu luo taulusi, käske sen kirjoittaa oikeudet, RLS ja politiikat samaan migraatioon. Virheen vihje on kirjoitettu niin, että agentti voi korjata oikeuden itse, mutta vihje nimeää vain oikeuden, ei RLS:ää, jonka pitäisi tulla mukaan.

Miten tarkistus näkee tämän?

Neljä sen säännöistä lukee oikeuskerrosta: “Oletusoikeudet, jotka avaavat uudet objektit API:lle” liputtaa projektit, jotka antavat edelleen uusille tauluille oikeudet automaattisesti, “Anonyymien kävijöiden käyttämättömät kirjoitusoikeudet” löytää anon-roolin kirjoitusoikeudet, joita mikään politiikka ei käytä, ja “Tarpeettomat tauluoikeudet kirjautuneille käyttäjille” löytää TRUNCATE-, TRIGGER- ja REFERENCES-oikeudet, kuten yllä olevat. “Käytännöt, jotka eivät koskaan toimi: roolilla ei ole oikeutta” listaa taulut, joissa käytäntö nimeää roolin, jolla ei ole oikeutta kyseiseen komentoon; juuri tältä uusi taulu näyttää 30. lokakuuta jälkeen. Miksi RLS on edelleen tärkeä oikeuden antamisen jälkeen, selviää artikkelista Supabase RLS:n testaus, ja miltä oikeudet ja politiikat näyttävät koko sovelluksessa, näkyy Lovable-sovelluksen tietoturvatarkistuslistassani.