Supabase „RLS disabled in public“: čo to znamená

Postavil som bezplatný bezpečnostný checker pre Supabase a jeho prvé pravidlo, „RLS vypnuté pri sprístupnených tabuľkách“, je ten istý nález, ktorý Security Advisor Supabase hlási ako chybu. Je to najčastejšia diera, ktorú nachádzam v aplikáciách postavených s AI nástrojmi, takže tu je, čo znamená a čo umožnila, keď som ju reprodukoval.

Čo znamená „RLS disabled in public“?

Security Advisor spúšťa lint rls_disabled_in_public. Jeho SQL označí tabuľku, keď platia tri veci naraz:

1. Je to obyčajná tabuľka s vypnutou row level security.
2. anon alebo authenticated na nej má SELECT.
3. Jej schéma je v zozname Exposed schemas Data API, čo je v predvolenom stave public.

Stránka lintu ho hodnotí ako ERROR a plný create, read, update a delete cez internet nazýva „kriticky nebezpečnou konfiguráciou“. „Public“ v názve je schéma, ale lint pokrýva každú sprístupnenú schému, a preto stojí za pohľad aj extra schéma na tomto zozname; písal som o tom v poznámke Supabase exposed schemas.

Čo môže verejný kľúč urobiť s takou tabuľkou?

Vytvoril som tabuľku orders s tromi fiktívnymi zákazníkmi na lokálnom Supabase (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), s grantmi, ktoré existujúce projekty dávajú novým tabuľkám, a s vypnutým RLS. Potom som volal Data API s publishable key, ako to robí prehliadač:

Požiadavka s publishable key	RLS vypnuté	RLS zapnuté, bez politiky
GET /rest/v1/orders?select=*	200, všetky 3 riadky s menami a e-mailmi	200, []
POST /rest/v1/orders s novým riadkom	201 Created	401, 42501 „new row violates row-level security policy“

Ktokoľvek, kto otvorí vašu aplikáciu, si môže skopírovať publishable key zo stránky. S vypnutým RLS je kľúč povolením na čítanie aj zápis do tej tabuľky.

Ako to opraviť, bez toho aby ste pokazili aplikáciu?

Samotné zapnutie RLS spôsobí, že tabuľka aplikácii nevráti nič, pretože ešte nie je žiadna politika. Práve vtedy ľudia, a AI nástroje, pridajú politiku s using (true), ktorá vráti každý riadok všetkým. Prečo update a delete potom hlásia úspech, ale nič nezmenia, je v článku How to enable RLS in Supabase: čo vráti po každom kroku. Skutočné politiky napíšte v rovnakej migrácii:

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

Ak má byť tabuľka verejná, napríklad zoznam publikovaných článkov, nechajte RLS aj tak zapnuté a napíšte jednu politiku select pre anon, bez zápisových grantov. Ak Data API nepoužívate a s Postgresom komunikujete len zo servera, odstráňte radšej public z Exposed schemas, ako v tom istom issue navrhli správcovia Supabase.

Aby nové tabuľky nikdy nezačínali bez RLS, má sprievodca event triggermi od Supabase trigger, ktorý RLS zapne na každej tabuľke vytvorenej v public. A od 30. októbra 2026 nové tabuľky nedostávajú v predvolenom stave žiadne granty Data API, takže odpovedajú 42501, kým im grant nedáte; písal som o tom v poznámke Supabase 42501 permission denied.

Čo čistý výsledok nedokazuje?

To, že je RLS zapnuté, nehovorí nič o tom, či sú politiky správne. V tom istom teste politika napísaná ako using (true) dala verejnému kľúču opäť všetky 3 riadky a tento lint mlčí, hneď ako je RLS zapnuté. Checker má na to samostatné pravidlo, „Politiky, ktoré povoľujú každý riadok“, a ako testovať Supabase RLS ukazuje, ako každú politiku dokázať proti skutočným používateľom. Politiky, od ktorých môžete začať, každú vyskúšanú proti skutočným používateľom cez API, sú v článku Supabase RLS policy: príklady otestované cez API.