Skener Supabase RLS: najděte tabulky s chybějícím nebo nefunkčním zabezpečením na úrovni řádků

Co dokáže externí sken RLS prokázat

Pasivní sken RLS pracuje proti koncovému bodu PostgREST, který Supabase vystavuje na adrese https://[project].supabase.co/rest/v1/. Používá pouze veřejný klíč anon — stejný klíč, jaký používá váš prohlížeč — a sonduje metadata seznamu tabulek, anonymní čtení a anonymní zápisy. Nikdy se neautentizuje jako uživatel a nikdy se nedotýká oprávnění servisní role. Cokoliv dokáže, dokáže i neověřený útočník na internetu.

Zvenčí databáze dokáže skener s vysokou jistotou potvrdit následující:

• RLS je na tabulce vypnuté. PostgREST vrací řádky pro anonymní SELECT, když je RLS vypnuté nebo když to politika povoluje. Oba případy jsou nálezem.
• Anonymní role může vypisovat tabulky. GET /rest/v1/ s anon klíčem vrátí OpenAPI schéma pro každou tabulku, na které má role anon jakékoliv oprávnění. Aplikace generované AI často udělují USAGE na schématu a SELECT na každé tabulce, což vystavuje úplnou mapu schématu i tehdy, když RLS skutečné čtení odmítá.
• Anonymní role může vkládat. Sondující POST s odhadem tvaru sloupce uspěje, pokud RLS nemá politiku INSERT, která by to odmítla — i když je SELECT uzamčen.
• Klíč servisní role je v balíčku prohlížeče. Sousedící s RLS: pokud skener najde SUPABASE_SERVICE_ROLE_KEY nebo jakýkoliv JWT s role: service_role v balíčku JavaScript, RLS je bezvýznamné — držitel tohoto klíče obchází každou politiku.

Co externí sken nedokáže prokázat

Buďte upřímní ohledně hranic skeneru. Externí sken RLS nedokáže přečíst vaši tabulku pg_policies, vaše migrační soubory ani přesný predikát žádné politiky. Vyvozuje závěry z chování černé skříňky, což znamená, že někdy nahlásí nález, který se ukáže být úmyslně veřejnými daty (tabulka marketingového newsletteru, veřejný katalog produktů). Zpráva FixVibe je označuje jako střední důvěru, když skener nedokáže rozlišit záměr — projděte název tabulky a rozhodněte.

Čtyři podoby rozbitého RLS, které vyrábějí AI nástroje

Když nasměrujete Cursor, Claude Code, Lovable nebo Bolt na Supabase, napříč tisíci aplikacemi se objevují stejné čtyři vzory rozbitého RLS. Každý projde typovou kontrolou, přeloží se a vydá:

Podoba 1: RLS nikdy nezapnut

Nejčastější typ selhání. Migrace vytvoří tabulku, ale vývojář (nebo AI nástroj) zapomene na ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST s radostí obsluhuje celou tabulku komukoliv, kdo má anon klíč. Oprava: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE není volitelné — bez něj vlastník tabulky (a každá role s vlastnictvím tabulky) obchází RLS.

ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.[name] FORCE  ROW LEVEL SECURITY;

Podoba 2: RLS zapnut, žádné politiky

Jemnější selhání. RLS je zapnuté, ale politiky nejsou napsané. Výchozí stav v PostgreSQL je odmítnout, takže ověření uživatelé nevidí nic — a vývojář přidá USING (true), aby aplikace fungovala, což všem umožní číst vše. Oprava: napište politiku omezenou podle auth.uid(): CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); a odpovídající politiku INSERT/UPDATE/DELETE.

CREATE POLICY "select_own"
  ON public.[name]
  FOR SELECT
  USING (auth.uid() = user_id);

Podoba 3: Politika porovnává sloupec sám se sebou

A copy-paste artefact. The developer writes <code>USING (user_id = user_id)</code> — which is always true — instead of <code>USING (auth.uid() = user_id)</code>. Type-checks pass; the policy permits every row. <strong>Fix:</strong> always compare a column to a function call (<code>auth.uid()</code>, <code>auth.jwt()->>'org_id'</code>, etc.), never to itself or to a constant.

Podoba 4: Politika na SELECT, ale ne na INSERT/UPDATE

Vývojář zamkne čtení, ale zapomene na zápisy. Politiky RLS jsou per-příkaz. FOR SELECT chrání pouze čtení; anonymní klient může stále INSERT, pokud žádná politika neodmítá. Oprava: napište politiku pro každý příkaz nebo použijte FOR ALL s explicitními klauzulemi USING a WITH CHECK.

Jak funguje skener Supabase RLS od FixVibe

Kontrola baas.supabase-rls probíhá ve třech fázích, každá s explicitními úrovněmi důvěry:

1. Fáze 1 — snímání otisků. Skener prochází nasazenou aplikaci, analyzuje její JavaScript balíček a vytahuje URL projektu Supabase a anon klíč z runtime konfigurace. Žádné odhadování DNS, žádný brute force — čte to, co čte prohlížeč.
2. Fáze 2 — objevení schématu. Jediný GET /rest/v1/ s anon klíčem vrátí OpenAPI schéma pro každou tabulku, kterou role anon vidí. Skener zaznamenává názvy tabulek, ale v této fázi nečte data řádků.
3. Fáze 3 — sondy čtení a zápisu. Pro každou objevenou tabulku skener vydá jeden anonymní SELECT s limit=1. Pokud se vrátí řádky, RLS je permisivní. Skener se tam zastaví — nevypisuje řádky, nestránkuje, neupravuje data. Sondy INSERT jsou podmíněny ověřeným vlastnictvím domény a explicitním souhlasem; nikdy nestřílejí proti neověřeným cílům.

Každý nález je dodán s přesnou URL požadavku, stavem odpovědi, tvarem odpovědi (pouze hlavičky) a názvem tabulky. AI návrh opravy ve spodní části nálezu je SQL blok ke zkopírování a vložení, který spustíte v SQL editoru Supabase.

Co dělat, když skener něco najde

Každý nález RLS je runtime nouzí. Veřejné koncové body PostgREST útočníci skenují během minut. Sekvence nápravy je mechanická:

1. Proveďte audit každé tabulky. Spusťte SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; v SQL editoru Supabase. Každý řádek s rowsecurity = false je problém.
2. Zapněte RLS na každé veřejné tabulce. Výchozí ENABLE ROW LEVEL SECURITY a FORCE ROW LEVEL SECURITY na každé vytvořené tabulce — udělejte z toho šablonu migrace.
3. Pište politiky příkaz po příkazu. Nepoužívejte FOR ALL USING (true). Napište explicitní politiky pro SELECT, INSERT, UPDATE, DELETE — každou s rozsahem podle auth.uid() nebo sloupce org-id z auth.jwt().
4. Ověřte druhým účtem. Zaregistrujte se jako jiný uživatel, zkuste přečíst záznamy jiného uživatele přímo přes REST API. Pokud je odpověď 200, politika je rozbitá.
5. Naskenujte znovu. Po aplikaci opravy znovu spusťte FixVibe sken proti stejné URL. Nález baas.supabase-rls by měl zmizet.

-- Audit every table for missing RLS. Run in the Supabase SQL editor.
SELECT schemaname, tablename, rowsecurity
FROM   pg_tables
WHERE  schemaname = 'public'
ORDER  BY rowsecurity, tablename;

Jak to vychází ve srovnání s jinými skenery

Většina obecných DAST nástrojů (Burp Suite, OWASP ZAP, Nessus) neví, co je PostgREST. Projdou vaši aplikaci, ignorují cestu /rest/v1/ a nahlásí HTML stránky, kterým rozumějí. Snyk a Semgrep jsou nástroje pro statickou analýzu — najdou migrační soubory ve vašem repu s chybějícími voláními RLS, ale nedokáží prokázat, že nasazená databáze je špatně nakonfigurovaná. FixVibe sedí v této mezeře: pasivní, s povědomím o BaaS, zaměřený na to, co může neověřený útočník prokázat z veřejné URL.

Často kladené otázky

Další kroky

Spusťte bezplatný FixVibe sken proti vaší produkční URL — kontrola baas.supabase-rls je zapnutá na každém tarifu včetně bezplatné úrovně. Pro hlubší pohled na to, co dalšího může uniknout z projektu Supabase, viz Servisní klíč Supabase vystavený v JavaScriptu a Kontrolní seznam zabezpečení úložného koše Supabase. Pro zastřešující pohled napříč všemi poskytovateli BaaS si přečtěte Skener chybných konfigurací BaaS.