Supabase 42501 permission denied: õigus, mitte RLS

Ehitasin tasuta Supabase’i turvakontrolli, mis loeb õigusi igal avaldatud tabelil, ja 42501 on viga, millega inimesed kokku puutuvad, kui õigused on valed vastupidises suunas: liiga vähe liiga palju asemel. Siin on, mida see tähendab ja mida nägin, kui seda reprodutseerisin.

Mida tähendab viga 42501 Supabase’is?

42501 on Postgresi kood puuduvate õiguste jaoks (insufficient privilege). Postgres kontrollib kahte kihti, enne kui klient tabelit puudutab: õigused (grants) otsustavad, kas roll tohib operatsiooni üldse teha, ja RLS-poliitikad otsustavad, millised read. Puuduv õigus ebaõnnestub esimesena, veana. Poliitika, mis ei sobi mitte ühegi reaga, ebaõnnestub vaikselt, tühja loendina. Seega kui näete 42501, vaadake õigusi, mitte poliitikaid.

PostgREST, supabase-js-i taga olev Data API, annab vea edasi vihjega. Minu kohalikul pinul (Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14) tagastas publishable key’ga päring tabelile, millel polnud rollile anon õigust, HTTP 401 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"
}

Miks saavad uued tabelid pärast 30. oktoobrit 2026 vea 42501?

Seni sai uus tabel skeemis public vaikeõiguste kaudu select, insert, update ja delete rollidele anon, authenticated ja service_role, seega oli see Data API kaudu kättesaadav hetkest, kui see loodi, kaitstud või mitte. Supabase’i changelog eemaldab need vaikeväärtused: valikuline alates 28. aprillist 2026, uute projektide vaikeväärtus alates 30. maist 2026 ja kõigile olemasolevatele projektidele rakendatud 30. oktoobril 2026. Olemasolevad tabelid säilitavad oma õigused.

Mida ümberlülitus veel katki teeb ja kuidas projekti enne kontrollida: Supabase 30. oktoobri grantide muudatus: mis läheb katki.

Rakendasin sama muudatuse oma kohalikule projektile kahe changelog’is oleva alter default privileges … revoke lausega ja lõin seejärel uue tabeli invoices:

Päring uuele tabelile	Tulemus
Publishable key, õigust pole	HTTP 401, 42501, vihje GRANT SELECT ON public.invoices TO anon;
Secret key, õigust pole	HTTP 403, 42501, vihje … TO service_role;
Publishable key, pärast grant select ja enable row level security	HTTP 200, [], kuni poliitika ridu lubab

Kaks asja üllatasid mind. Secret key’d keelatakse samuti: service_role jätab RLS-i vahele, kuid vajab siiski õigust, seega läheb Edge Function või serveritöö, mis uude tabelisse kirjutab, samamoodi katki. Ja revoke võtab tagasi ainult need neli operatsiooni: uus tabel tuli endiselt koos REFERENCES, TRIGGER ja TRUNCATE õigustega rollidele anon, authenticated ja service_role. Ükski poliitika ei kehti TRUNCATE-ile.

Kuidas parandada 42501 tabelit avamata?

Käsitlege õigust, RLS-i ja poliitikat ühe muudatusena, ühes migratsioonis, ning andke igale rollile ainult see, mida see vajab:

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 kustutab esmalt TRUNCATE, TRIGGER ja REFERENCES, mis tabeliga kaasa tulid. Ärge vastake 42501-le käsuga grant all on all tables in schema public to anon: see on vana vaikeväärtus tagasi, kõigile tabelitele korraga, ja iga tabel ilma RLS-ita muutub loetavaks igaühele, kellel on teie avalik võti.

Kui teie tabeleid loob AI tööriist, öelge sellele, et see väljastaks õigused, RLS-i ja poliitikad samas migratsioonis. Vea vihje on kirjutatud nii, et agent saab õiguse ise parandada, kuid vihje nimetab ainult õigust, mitte RLS-i, mis sellega kaasas peaks käima.

Kuidas kontroll seda näeb?

Neli selle reeglit loevad õiguste kihti: “Vaikeõigused, mis avavad uued objektid API-le” märgib projektid, mis annavad uusi tabeleid endiselt automaatselt, “Anonüümsete külastajate kasutamata kirjutusõigused” leiab anon kirjutusõigused, mida ükski poliitika ei kasuta, ja “Sisselogitud kasutajate tarbetud tabeliõigused” leiab TRUNCATE, TRIGGER ja REFERENCES nagu ülalolevad. “Poliitikad, mis ei tööta kunagi: rollil puudub grant” loetleb tabelid, kus poliitika nimetab rolli, millel pole selle käsu jaoks granti, ja just nii näeb uus tabel välja pärast 30. oktoobrit. Miks RLS loeb ka pärast õiguse andmist, on artiklis kuidas Supabase’i RLS-i testida, ja kuidas õigused ja poliitikad välja näevad kogu rakenduses, on minu Lovable’i rakenduse turvanimekirjas.