Skener Supabase RLS: nájdite tabuľky s chýbajúcim alebo nefunkčným zabezpečením na úrovni riadkov

Čo dokáže externý sken RLS preukázať

Pasívny sken RLS pracuje proti koncovému bodu PostgREST, ktorý Supabase vystavuje na adrese https://[project].supabase.co/rest/v1/. Používa iba verejný kľúč anon — rovnaký kľúč, aký používa váš prehliadač — a sonduje metadáta zoznamu tabuliek, anonymné čítania a anonymné zápisy. Nikdy sa neautentizuje ako používateľ a nikdy sa nedotýka oprávnení servisnej role. Čokoľvek dokáže, dokáže aj neoverený útočník na internete.

Zvonku databázy dokáže skener s vysokou istotou potvrdiť nasledujúce:

• RLS je na tabuľke vypnuté. PostgREST vracia riadky pre anonymný SELECT, keď je RLS vypnuté alebo keď to politika povoľuje. Oba prípady sú nálezom.
• Anonymná rola môže vypisovať tabuľky. GET /rest/v1/ s anon kľúčom vráti OpenAPI schému pre každú tabuľku, na ktorej má rola anon akékoľvek oprávnenie. Aplikácie generované AI často udeľujú USAGE na schéme a SELECT na každej tabuľke, čo vystavuje úplnú mapu schémy aj vtedy, keď RLS skutočné čítania odmieta.
• Anonymná rola môže vkladať. Sondujúci POST s odhadom tvaru stĺpca uspeje, ak RLS nemá politiku INSERT, ktorá by to odmietla — aj keď je SELECT uzamknutý.
• Kľúč servisnej role je v balíčku prehliadača. Susediace s RLS: ak skener nájde SUPABASE_SERVICE_ROLE_KEY alebo akýkoľvek JWT s role: service_role v balíčku JavaScript, RLS je bezvýznamné — držiteľ tohto kľúča obchádza každú politiku.

Čo externý sken nedokáže preukázať

Buďte úprimní ohľadom hraníc skenera. Externý sken RLS nedokáže čítať vašu tabuľku pg_policies, vaše migračné súbory ani presný predikát žiadnej politiky. Odvodzuje zo správania čiernej skrinky, čo znamená, že niekedy nahlási nález, ktorý sa ukáže ako zámerne verejné dáta (tabuľka marketingového newslettera, verejný katalóg produktov). Správa FixVibe ich označí ako so strednou istotou, keď skener nedokáže rozlíšiť úmysel — preskúmajte názov tabuľky a rozhodnite sa.

Štyri podoby pokazeného RLS, ktoré AI nástroje produkujú

Keď nasmerujete Cursor, Claude Code, Lovable alebo Bolt na Supabase, naprieč tisíckami aplikácií vyplávajú rovnaké štyri vzory pokazeného RLS. Každý z nich prejde typovou kontrolou, preloží sa a vydá:

Podoba 1: RLS nikdy nezapnuté

Najčastejší spôsob zlyhania. Migrácia vytvorí tabuľku, ale vývojár (alebo AI nástroj) zabudne na ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST s radosťou poskytuje celú tabuľku komukoľvek s anon kľúčom. Oprava: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE nie je voliteľné — bez neho vlastník tabuľky (a každá rola s vlastníctvom tabuľky) obchádza RLS.

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

Podoba 2: RLS zapnuté, žiadne politiky

Jemnejšie zlyhanie. RLS je zapnuté, ale žiadne politiky nie sú napísané. Predvolené správanie v PostgreSQL je odmietnuť, takže overení používatelia nevidia nič — a vývojár pridá USING (true), aby aplikácia fungovala, čo umožňuje každému čítať všetko. Oprava: napíšte politiku, ktorá rozlišuje podľa auth.uid(): CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); a zodpovedajúcu politiku INSERT/UPDATE/DELETE.

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

Podoba 3: Politika porovnáva stĺpec sám so 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 nie na INSERT/UPDATE

Vývojár uzamkne čítania, ale zabudne na zápisy. RLS politiky sú jednotlivo pre každý príkaz. FOR SELECT chráni iba čítania; anonymný klient môže stále spraviť INSERT, ak to žiadna politika neodmieta. Oprava: napíšte politiku pre každý príkaz, alebo použite FOR ALL s explicitnými klauzulami USING a WITH CHECK.

Ako funguje skener Supabase RLS od FixVibe

Kontrola baas.supabase-rls beží v troch fázach, každá s explicitnými úrovňami istoty:

1. Fáza 1 — snímanie odtlačku. Skener prechádza nasadenú aplikáciu, analyzuje jej JavaScript balíček a extrahuje URL projektu Supabase a anon kľúč z behovej konfigurácie. Žiadne hádanie DNS, žiadny brute force — číta to, čo číta prehliadač.
2. Fáza 2 — objavovanie schémy. Jediný GET /rest/v1/ s anon kľúčom vráti OpenAPI schému pre každú tabuľku, ktorú anon rola môže vidieť. Skener zaznamená názvy tabuliek, ale v tejto fáze nečíta dáta riadkov.
3. Fáza 3 — sondy čítania a zápisu. Pre každú objavenú tabuľku skener vydá jeden anonymný SELECT s limit=1. Ak sa vrátia riadky, RLS je voľné. Skener sa tam zastaví — nevypisuje riadky, nestránkuje, neupravuje dáta. INSERT sondy sú podmienené overeným vlastníctvom domény a explicitným súhlasom; nikdy nestrieľajú proti neovereným cieľom.

Každý nález prichádza s presnou URL požiadavky, stavom odpovede, tvarom odpovede (iba hlavičky) a názvom tabuľky. AI návrh opravy v spodnej časti nálezu je SQL blok na skopírovanie a vloženie, ktorý spustíte v Supabase SQL editore.

Čo robiť, keď skener niečo nájde

Každý nález RLS je behová núdza. Verejné PostgREST koncové body sú skenované útočníkmi v priebehu minút. Postupnosť nápravy je mechanická:

1. Auditujte každú tabuľku. Spustite SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; v Supabase SQL editore. Akýkoľvek riadok s rowsecurity = false je problém.
2. Zapnite RLS na každej verejnej tabuľke. Štandardne použite ENABLE ROW LEVEL SECURITY a FORCE ROW LEVEL SECURITY na každej vytvorenej tabuľke — urobte z toho šablónu migrácie.
3. Píšte politiky príkaz po príkaze. Nepoužívajte FOR ALL USING (true). Napíšte explicitné politiky pre SELECT, INSERT, UPDATE, DELETE — každú obmedzenú na auth.uid() alebo stĺpec org-id z auth.jwt().
4. Overte druhým účtom. Zaregistrujte sa ako iný používateľ a skúste prečítať záznamy iného používateľa priamo cez REST API. Ak je odpoveď 200, politika je pokazená.
5. Naskenujte znova. Po aplikovaní opravy znova spustite sken FixVibe proti rovnakej URL. Nález baas.supabase-rls by mal zmiznúť.

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

Ako sa to porovnáva s inými skenermi

Väčšina generických DAST nástrojov (Burp Suite, OWASP ZAP, Nessus) nevie, čo je PostgREST. Prejdú vašu aplikáciu, ignorujú cestu /rest/v1/ a hlásia HTML stránky, ktorým rozumejú. Snyk a Semgrep sú nástroje statickej analýzy — nájdu migračné súbory vo vašom repozitári s chýbajúcimi volaniami RLS, ale nedokážu preukázať, že nasadená databáza je chybne nakonfigurovaná. FixVibe sedí v medzere: pasívny, BaaS-vedomý, zameraný na to, čo dokáže neoverený útočník preukázať z verejnej URL.

Často kladené otázky

Ďalšie kroky

Spustite bezplatný sken FixVibe proti vašej produkčnej URL — kontrola baas.supabase-rls je zapnutá v každom pláne vrátane bezplatnej úrovne. Pre hlbšie čítanie o tom, čo ďalšie môže uniknúť z projektu Supabase, pozrite Kľúč servisnej role Supabase odhalený v JavaScripte a Kontrolný zoznam zabezpečenia Supabase Storage. Pre zastrešujúci pohľad naprieč všetkými BaaS poskytovateľmi si prečítajte Skener chybnej konfigurácie BaaS.