Supabase RLS-skanni: finndu töflur með vantandi eða bilaða row-level security

Hvað utanaðkomandi RLS-skönnun getur sannað

Hlutlaus RLS-skönnun keyrir gegn PostgREST-endapunktinum sem Supabase opnar á https://[project].supabase.co/rest/v1/. Hún notar aðeins útgefanlega anon-lykilinn — sama lykilinn og vafrinn þinn notar — og kannar lýsigögn yfir töflur, ókenndar lestur og ókenndar skrifanir. Hún auðkennir sig aldrei sem notanda og snertir aldrei service-role réttindi. Allt sem hún getur gert, getur ókenndur árásarmaður á internetinu líka gert.

Utan við gagnagrunninn getur skanni staðfest eftirfarandi með mikilli vissu:

• RLS er óvirkjuð á töflu. PostgREST skilar röðum fyrir ókennda SELECT þegar RLS er slökkt eða þegar stefna leyfir það. Báðir tilfellin eru niðurstaða.
• Ókennda hlutverkið getur listað töflur. GET /rest/v1/ með anon-lyklinum skilar OpenAPI-skemanu fyrir hverja töflu sem hlutverkið anon hefur einhver réttindi á. AI-mynduð forrit veita oft USAGE á skemanu og SELECT á hverri töflu, sem opnar allan skemakortið jafnvel þegar RLS hafnar raunverulegum lestrum.
• Ókennda hlutverkið getur sett inn. Könnunar-POST með ágiskun á dálkasniðið mun heppnast ef RLS hefur ekki INSERT-stefnu sem hafnar honum — jafnvel þó að SELECT sé læstur niður.
• Service-role-lykillinn er í vafraknippinu. Tengt RLS: ef skanni finnur SUPABASE_SERVICE_ROLE_KEY eða einhverja JWT með role: service_role í JavaScript-knippinu, þá er RLS marklaus — handhafi þess lykils sniðgengur sérhverja stefnu.

Hvað utanaðkomandi skönnun getur ekki sannað

Vertu hreinskilinn um mörk skannarsins. Utanaðkomandi RLS-skönnun getur ekki lesið pg_policies-töfluna þína, flutningsskrárnar þínar eða nákvæmu forsendu nokkurrar stefnu. Hún ályktar af svartakassa-hegðun, sem þýðir að hún tilkynnir stundum niðurstöðu sem reynist vera viljandi opinber gögn (markaðsfréttabréfstafla, opinber vörulisti). FixVibe-skýrslan merkir þessar sem meðal vissu þegar skanninn getur ekki greint ætlun á milli — skoðaðu töflunafnið og ákveddu.

Fjórar bilaðar RLS-tegundir sem AI-verkfæri framleiða

Þegar þú beinir Cursor, Claude Code, Lovable eða Bolt að Supabase, koma sömu fjórar biluðu RLS-mynstrin upp í þúsundum forrita. Hvert þeirra stenst týpuathugun, þýðist og sendist:

Tegund 1: RLS aldrei virkjuð

Algengasta bilunarásigkomulagið. Flutningurinn býr til töfluna en þróunaraðilinn (eða AI-verkfærið) gleymir ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST framreiðir glaðlega alla töfluna fyrir hvern sem hefur anon-lykilinn. Lagfæring: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE er ekki valfrjálst — án þess sniðgengur töflueigandinn (og sérhvert hlutverk með töflueignarhald) RLS.

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

Tegund 2: RLS virkjuð, engar stefnur

Lúmskari bilun. RLS er virkjuð en engar stefnur eru skrifaðar. Sjálfgildið í PostgreSQL er hafna, þannig að auðkenndir notendur sjá ekkert — og þróunaraðilinn bætir við USING (true) til að láta forritið virka, sem leyfir öllum að lesa allt. Lagfæring: skrifaðu stefnu sem afmarkast af auth.uid(): CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); og samsvarandi INSERT/UPDATE/DELETE-stefnu.

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

Tegund 3: Stefna ber saman dálk við sjálfan sig

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.

Tegund 4: Stefna á SELECT en ekki á INSERT/UPDATE

Þróunaraðilinn læsir lestur niður en gleymir skrifum. RLS-stefnur eru fyrir hverja skipun. FOR SELECT verndar aðeins lestur; ókenndur biðlari getur enn INSERT ef engin stefna hafnar því. Lagfæring: skrifaðu stefnu fyrir hverja skipun, eða notaðu FOR ALL með skýrum USING- og WITH CHECK-ákvæðum.

Hvernig FixVibe Supabase RLS-skanninn virkar

baas.supabase-rls-athugunin keyrir í þremur þrepum, hvert með skýrum vissustigum:

1. Þrep 1 — fingrafar. Skanninn skríður á uppsetta forritið, þáttar JavaScript-knippið og dregur fram Supabase-verkefnis-URL og anon-lykilinn úr keyrslustillingunni. Engar DNS-ágiskanir, engin brute force — það les það sem vafrinn les.
2. Þrep 2 — skemauppgötvun. Eitt GET /rest/v1/ með anon-lyklinum skilar OpenAPI-skemanu fyrir hverja töflu sem anon-hlutverkið sér. Skanninn skráir töflunöfn en les ekki raðagögn á þessu þrepi.
3. Þrep 3 — lestrar- og skrifkannanir. Fyrir hverja uppgötvaða töflu gefur skanninn út eitt ókennt SELECT með limit=1. Ef raðir skila sér er RLS leyfileg. Skanninn stoppar þar — hann telur ekki upp raðir, síðunúmerar ekki, breytir engum gögnum. INSERT-kannanir eru aðgangsstýrðar með staðfestu lénseignarhaldi og skýru opt-in; þær keyra aldrei gegn óstaðfestum markmiðum.

Hver niðurstaða fylgir nákvæmum beiðnar-URL, svarstöðu, svarsniði (aðeins haus) og töflunafni. AI-lagfæringarspurningin neðst í niðurstöðunni er copy-paste SQL-blokk sem þú keyrir í Supabase SQL-ritlinum.

Hvað á að gera þegar skanninn finnur eitthvað

Sérhver RLS-niðurstaða er keyrsluneyðarástand. Opinberir PostgREST-endapunktar eru skannaðir af árásarmönnum á mínútum. Lagfæringarröðin er vélræn:

1. Endurskoðaðu hverja töflu. Keyrðu SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; í Supabase SQL-ritlinum. Sérhver röð með rowsecurity = false er vandamál.
2. Virkjaðu RLS á sérhverri opinberri töflu. Sjálfgildið skal vera ENABLE ROW LEVEL SECURITY og FORCE ROW LEVEL SECURITY á sérhverri stofnaðri töflu — gerðu það að flutningssniðmáti.
3. Skrifaðu stefnur skipun fyrir skipun. Ekki nota FOR ALL USING (true). Skrifaðu skýrar stefnur fyrir SELECT, INSERT, UPDATE, DELETE — hver afmörkuð við auth.uid() eða org-id-dálk frá auth.jwt().
4. Staðfestu með öðrum aðgangi. Skráðu þig inn sem annar notandi, reyndu að lesa færslur annars notanda beint í gegnum REST-API. Ef svarið er 200 er stefnan biluð.
5. Skannaðu aftur. Eftir að hafa beitt lagfæringunni, keyrðu FixVibe-skönnun aftur gegn sömu URL. baas.supabase-rls-niðurstaðan ætti að hverfa.

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

Hvernig þetta ber saman við aðra skanna

Flest almenn DAST-verkfæri (Burp Suite, OWASP ZAP, Nessus) vita ekki hvað PostgREST er. Þau skríða um forritið þitt, hunsa /rest/v1/-slóðina og tilkynna um HTML-síðurnar sem þau skilja. Snyk og Semgrep eru kyrrstöðugreiningarverkfæri — þau finna flutningsskrár í endurhverfunni þinni með vantandi RLS-köllum, en geta ekki sannað að uppsetti gagnagrunnurinn sé rangstilltur. FixVibe sest í gatið: hlutlaus, BaaS-meðvituð, einbeitt að því sem ókenndur árásarmaður getur sannað utan frá opinberu URL-i.

Algengar spurningar

Næstu skref

Keyrðu ókeypis FixVibe-skönnun gegn framleiðslu-URL þínum — baas.supabase-rls-athugunin er virk á öllum áskriftum, þar á meðal ókeypis stigi. Fyrir dýpri lestur á því hvað annað getur lekið frá Supabase-verkefni, sjáðu Supabase service-role-lykill opinberaður í JavaScript og Supabase geymslufötu öryggisgátlisti. Fyrir regnhlífaryfirlit yfir allar BaaS-veitur, lestu BaaS-rangstillingaskanni.