Supabase "RLS disabled in public": ko tas nozīmē

Es izveidoju bezmaksas Supabase drošības pārbaudi, un tās pirmais noteikums “RLS izslēgts atklātajām tabulām” ir tas pats atradums, ko Supabase Security Advisor ziņo kā kļūdu. Tas ir biežākais robs, ko atrodu ar AI rīkiem veidotās lietotnēs, tāpēc lūk, ko tas nozīmē un ko tas pieļāva, kad es to atkārtoju.

Ko nozīmē “RLS disabled in public”?

Security Advisor palaiž lint ar nosaukumu rls_disabled_in_public. Tā SQL atzīmē tabulu, kad vienlaikus ir patiesas trīs lietas:

1. Tā ir parasta tabula ar izslēgtu row level security.
2. anon vai authenticated tai ir SELECT.
3. Tās shēma ir Data API sarakstā Exposed schemas, kas pēc noklusējuma ir public.

Lint lapa to novērtē kā ERROR un pilnu create, read, update un delete piekļuvi internetā sauc par “kritiski nedrošu konfigurāciju” (“a critically unsafe configuration”). “Public” nosaukumā ir shēma, taču lint aptver katru atklāto shēmu, tāpēc uzmanību pelna arī papildu shēma šajā sarakstā; par to rakstīju piezīmē Supabase exposed schemas.

Ko publiskā atslēga var izdarīt ar šādu tabulu?

Lokālā Supabase vidē (CLI 2.109.1, Postgres 17.6, PostgREST 14.14) izveidoju tabulu orders ar trim izdomātiem klientiem, ar tiesībām, kādas esošie projekti piešķir jaunām tabulām, un izslēgtu RLS. Tad izsaucu Data API ar publishable key, kā to dara pārlūks:

Pieprasījums ar publishable key	RLS izslēgts	RLS ieslēgts, politikas nav
GET /rest/v1/orders?select=*	200, visas 3 rindas ar vārdiem un e-pastiem	200, []
POST /rest/v1/orders ar jaunu rindu	201 Created	401, 42501 “new row violates row-level security policy”

Ikviens, kas atver jūsu lietotni, var nokopēt publishable key no lapas. Ja RLS ir izslēgts, šī atslēga ir lasīšanas un rakstīšanas caurlaide uz šo tabulu.

Kā to labot, nesalaužot lietotni?

Vienkārši ieslēdzot RLS, tabula lietotnei neatgriež neko, jo politikas vēl nav. Tieši šajā tukšajā ekrānā cilvēki un AI rīki pievieno politiku ar using (true), kas visas rindas atdod ikvienam. Kāpēc update un delete tad ziņo par veiksmi, neko nemainot, ir rakstā Enable RLS in Supabase: ko tabula atgriež pēc tam. Rakstiet īstās politikas tajā pašā migrācijā:

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

Ja tabula ir paredzēta publiskai lietošanai, piemēram, publicēto rakstu saraksts, RLS tāpat atstājiet ieslēgtu un uzrakstiet vienu select politiku lomai anon, bez rakstīšanas tiesībām. Ja Data API nekad neizmantojat un ar Postgres runājat tikai no sava servera, tā vietā noņemiet public no Exposed schemas, kā Supabase uzturētāji ieteica tajā pašā issue.

Lai jaunas tabulas nekad nesāktos bez RLS, Supabase event triggers ceļvedī ir trigeris, kas ieslēdz to katrai tabulai, kas izveidota shēmā public. Un no 2026. gada 30. oktobra jaunas tabulas pēc noklusējuma nesaņem Data API tiesības, tāpēc tās atbild ar 42501, kamēr tiesības nepiešķirat; to aplūkoju piezīmē Supabase 42501 permission denied.

Ko tīrs rezultāts nepierāda?

Tas, ka RLS ir ieslēgts, neko nesaka par to, vai politikas ir pareizas. Tajā pašā testā politika using (true) publiskajai atslēgai atkal deva visas 3 rindas, un šis lint paliek kluss, tiklīdz RLS ir ieslēgts. Pārbaudei tam ir atsevišķs noteikums, “Politikas, kas atļauj visas rindas”, un kā es testēju Supabase RLS parāda, kā pierādīt katru politiku ar īstiem lietotājiem. Politikas, ar kurām sākt, katra palaista pret īstiem lietotājiem caur API, ir rakstā Supabase RLS policy piemēri, pārbaudīti caur API.