Scanner RLS Supabase: trova tabelle cù sicurezza à livellu di riga mancante o rotta

Ciò chì una scansione RLS esterna pò pruvà

Una scansione RLS passiva gira contru à l'endpoint PostgREST chì Supabase espone à https://[project].supabase.co/rest/v1/. Adopra solu a chjave publishable anon — listessa chì u to navigatore adopra — è sonda metadata di lista di tabelle, letture anonime è scritture anonime. Ùn s'autentica mai cum'è un utente è ùn tocca mai privileghji di service-role. Qualcosa pò fà, un attaccante micca autenticatu in internet pò fà.

Da fora di a basa di dati, un scanner pò cunfirmà ciò chì seguita cù alta fiducia:

• RLS hè disattivatu nantu à una tabella. PostgREST torna righe per un SELECT anonimu quandu RLS hè spentu o quandu una pulitica u permette. I dui casi sò un risultatu.
• U rolu anonimu pò listà e tabelle. Un GET /rest/v1/ cù a chjave anon torna u schema OpenAPI per ogni tabella nantu à chì u rolu anon hà qualunque privileghju. L'app generate da IA spessu cuncedanu USAGE nantu à u schema è SELECT nantu à ogni tabella, ciò chì espone a carta sana di u schema ancu quandu RLS nega e letture vere.
• U rolu anonimu pò inserà. Un POST di sondaghju cù una supposizione di a forma di e colonne riesce s'è RLS ùn hà micca una pulitica INSERT chì u nega — ancu s'è SELECT hè chjusu.
• A chjave di service-role hè in u bundle di u navigatore. Vicinu à RLS: s'è un scanner trova SUPABASE_SERVICE_ROLE_KEY o qualunque JWT cù role: service_role in u bundle JavaScript, RLS hè irrilevante — u titulare di quella chjave passa sopra ogni pulitica.

Ciò chì una scansione esterna ùn pò pruvà

Sia onestu nantu à i limiti di u scanner. Una scansione RLS esterna ùn pò leghje a to tabella pg_policies, i to schedarii di migrazione o u predicatu esattu di qualunque pulitica. Inferisce da u cumpurtamentu black-box, ciò chì vole dì ch'ella sgnalerà à volte un risultatu chì si svela esse datu publicu vulutu (una tabella di newsletter di marketing, un catalogu prudottu publicu). U raportu FixVibe i marca cum'è fiducia media quandu u scanner ùn pò micca disambiguà l'intenzione — rivedi u nome di a tabella è decidi.

E quattru forme di RLS rotta chì l'attrezzi IA producenu

Quandu punti Cursor, Claude Code, Lovable, o Bolt à Supabase, listessi quattru pattern di RLS rotta emergenu trà mille di app. Ognunu passa u type-check, compila è parte:

Forma 1: RLS mai attivatu

U modu di fallimentu più cumunu. A migrazione crea a tabella ma u sviluppatore (o l'attrezzu IA) si scorda ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST serve cuntentu a tabella sana à chì abbia a chjave anon. Currezzione: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE ùn hè opzionale — senza ellu u patrone di a tabella (è ogni rolu cù pruprietà di tabella) passa sopra RLS.

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

Forma 2: RLS attivatu, nessuna pulitica

Un fallimentu più sutile. RLS hè attivatu ma nesuna pulitica hè scritta. U difettu in PostgreSQL hè nega, dunque l'utenti autenticati ùn vedenu nunda — è u sviluppatore aghjusta USING (true) per fà funziunà l'app, ciò chì permette à tutti di leghje tuttu. Currezzione: scrivi una pulitica chì limita per auth.uid(): CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); è una pulitica INSERT/UPDATE/DELETE currispundente.

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

Forma 3: pulitica paragona colonna cù ella stessa

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.

Forma 4: pulitica nantu à SELECT ma micca nantu à INSERT/UPDATE

U sviluppatore chjude e letture ma si scorda e scritture. E pulitiche RLS sò per-cumandu. FOR SELECT prutege solu e letture; un cliente anonimu pò sempre INSERT s'è nesuna pulitica u nega. Currezzione: scrivi una pulitica per cumandu, o adopra FOR ALL cù clausule USING è WITH CHECK esplicite.

Cumu funziona u scanner RLS Supabase di FixVibe

U check baas.supabase-rls gira in trè tappe, ognuna cù livelli di fiducia espliciti:

1. Tappa 1 — fingerprint. U scanner crawla l'app spiegata, analizza u so bundle JavaScript è estrae l'URL di u prughjettu Supabase è a chjave anon da a cunfigurazione runtime. Nisun DNS guessing, nisun brute force — leghje ciò chì leghje u navigatore.
2. Tappa 2 — scuperta di schema. Un sulu GET /rest/v1/ cù a chjave anon torna u schema OpenAPI per ogni tabella chì u rolu anon pò vede. U scanner registra i nomi di e tabelle ma ùn leghje micca dati di righe in sta tappa.
3. Tappa 3 — sondaghji di lettura è scrittura. Per ogni tabella scuperta, u scanner emette un SELECT anonimu cù limit=1. S'è ritornanu righe, RLS hè permissivu. U scanner si ferma quì — ùn enumera righe, ùn pagina, ùn modifica dati. I sondaghji INSERT sò gattati daretu à verifica di pruprietà di duminiu è opt-in esplicitu; ùn parteranu mai contru à miri micca verificati.

Ogni risultatu vene cù l'URL esatta di a richiesta, u statutu di a risposta, a forma di a risposta (solu testa) è u nome di a tabella. U suggerimentu di currezzione IA in fondu à u risultatu hè un bloccu SQL prontu à incolla chì lampi in l'editore SQL di Supabase.

Ciò chì fà quandu u scanner trova qualcosa

Ogni risultatu RLS hè una emergenza in runtime. L'endpoint PostgREST pubblichi sò scansiunati da l'attaccanti in minuti. A sequenza di remediazione hè meccanica:

1. Auditeghja ogni tabella. Lampa SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; in l'editore SQL di Supabase. Ogni riga cù rowsecurity = false hè un prublema.
2. Attiveghja RLS nantu à ogni tabella pubblica. Per difettu, applica ENABLE ROW LEVEL SECURITY è FORCE ROW LEVEL SECURITY nantu à ogni tabella creata — fànne un mudellu di migrazione.
3. Scrivi pulitiche cumandu per cumandu. Ùn aduprà FOR ALL USING (true). Scrivi pulitiche esplicite per SELECT, INSERT, UPDATE, DELETE — ognuna limitata à auth.uid() o à una colonna org-id da auth.jwt().
4. Verifica cù un secondu cunto. Iscriviti cum'è un utente sfarente, prova à leghje i registri di un altru utente via l'API REST direttamente. S'è a risposta hè 200, a pulitica hè rotta.
5. Riscaneghja. Dopu avè applicatu a currezzione, lampa di novu una scansione FixVibe contru à listessu URL. U risultatu baas.supabase-rls deve sparisce.

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

Cumu si paragona à altri scanner

A maiò parte di l'attrezzi DAST generichi (Burp Suite, OWASP ZAP, Nessus) ùn sanu ciò chì hè PostgREST. Anu da crawlà a to app, ignurà u percorsu /rest/v1/, è raportà nantu à e pagine HTML chì capiscenu. Snyk è Semgrep sò attrezzi d'analisi statica — trovanu schedarii di migrazione in u to repo cù chjamate RLS mancante, ma ùn ponu pruvà chì a basa di dati spiegata hè mal cunfigurata. FixVibe stà in u spaziu: passivu, BaaS-cunsciu, focalizatu nantu à ciò chì un attaccante micca autenticatu pò pruvà da l'URL pubblicu.

Dumande frequenti

Prussimi passi

Lampa una scansione FixVibe gratisa contru à u to URL di produzzione — u check baas.supabase-rls hè attivatu in ogni pianu cumpresu u pianu gratisi. Per una lettura più prufonda nantu à ciò chì altru pò perde da un prughjettu Supabase, vedi Chjave di service-role Supabase esposta in JavaScript è Lista di cuntrollu di sicurezza di bucket Supabase Storage. Per a vista d'imbrelli trà tutti i fornitori BaaS, leghji Scanner di sbagli di cunfigurazione BaaS.