Supabase "RLS disabled in public": mida see tähendab

Ehitasin tasuta Supabase’i turvakontrolli ja selle esimene reegel, “RLS keelatud avalikel tabelitel”, on sama leid, mida Supabase’i Security Advisor veana raporteerib. See on kõige sagedasem auk, mida AI tööriistadega ehitatud rakendustes leian, nii et siin on, mida see tähendab ja mida see lubas, kui seda reprodutseerisin.

Mida tähendab “RLS disabled in public”?

Security Advisor käivitab lint’i nimega rls_disabled_in_public. Selle SQL märgib tabeli, kui kolm asja on korraga tõesed:

1. See on tavaline tabel, millel on row level security väljas.
2. Rollil anon või authenticated on sellel SELECT.
3. Selle skeem on Data API Exposed schemas nimekirjas, mis on vaikimisi public.

Lint’i leht hindab selle tasemele ERROR ja nimetab täielikku create-, read-, update- ja delete-juurdepääsu üle interneti “kriitiliselt ebaturvaliseks konfiguratsiooniks” (“a critically unsafe configuration”). Nimes olev “public” on skeem, kuid lint katab iga avaldatud skeemi, mistõttu väärib pilku ka nimekirja lisatud skeem; kirjutasin sellest märkuses Supabase exposed schemas.

Mida avalik võti sellise tabeliga teha saab?

Lõin kohalikul Supabase’i pinul (CLI 2.109.1, Postgres 17.6, PostgREST 14.14) tabeli orders kolme võltskliendiga, õigustega, mille olemasolevad projektid uutele tabelitele annavad, ja RLS väljas. Seejärel kutsusin Data API-t publishable key’ga, nagu brauser teeb:

Päring publishable key’ga	RLS väljas	RLS sees, poliitikat pole
GET /rest/v1/orders?select=*	200, kõik 3 rida nimede ja e-postidega	200, []
POST /rest/v1/orders uue reaga	201 Created	401, 42501 “new row violates row-level security policy”

Igaüks, kes teie rakenduse avab, saab publishable key kopeerida lehelt. Kui RLS on väljas, on see võti selle tabeli lugemis- ja kirjutamispääs.

Kuidas seda rakendust lõhkumata parandada?

Pelgalt RLS-i sisselülitamine paneb tabeli rakendusele mitte midagi tagastama, sest poliitikat pole veel. Seda tühja ekraani nähes lisavad inimesed ja AI tööriistad poliitika using (true), mis annab iga rea kõigile tagasi. Miks update ja delete siis teatavad õnnestumisest, ilma midagi muutmata, on artiklis Enable RLS in Supabase: mida tabel pärast tagastab. Kirjutage päris poliitikad samas migratsioonis:

alter table public.orders enable row level security;

revoke all on table public.orders from anon, authenticated;
grant select, insert on table public.orders to authenticated;

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

create policy "Customers create their orders"
on public.orders for insert
to authenticated
with check ((select auth.uid()) = user_id);

Kui tabel on mõeldud avalikuks, näiteks avaldatud artiklite loend, hoidke RLS siiski sees ja kirjutage üks select poliitika rollile anon, ilma kirjutusõigusteta. Kui te Data API-t kunagi ei kasuta ja räägite Postgresiga ainult oma serverist, eemaldage hoopis public nimekirjast Exposed schemas, nagu Supabase’i hooldajad samas issue’s soovitasid.

Et uued tabelid kunagi ilma RLS-ita ei alustaks, on Supabase’i event triggers juhendis trigger, mis lülitab selle sisse igal skeemis public loodud tabelil. Ja alates 30. oktoobrist 2026 ei saa uued tabelid vaikimisi Data API õigusi, nii et need vastavad 42501-ga, kuni te õigused annate; kattisin seda märkuses Supabase 42501 permission denied.

Mida puhas tulemus ei tõesta?

See, et RLS on sees, ei ütle midagi selle kohta, kas poliitikad on õiged. Samas testis andis poliitika kujul using (true) avalikule võtmele jälle kõik 3 rida ja see lint jääb vaikseks, kui RLS on sees. Kontrollil on selleks eraldi reegel, “Poliitikad, mis lubavad kõik read”, ja kuidas Supabase’i RLS-i testida näitab, kuidas iga poliitikat päris kasutajatega tõestada. Poliitikad, millest alustada, igaüks päris kasutajatega API kaudu käivitatud, on artiklis Supabase RLS policy näited, testitud API kaudu.