FixVibe
Covered by FixVibehigh

Accesso ai dati non autorizzato tramite sicurezza a livello di riga Supabase mancante (RLS)

Nelle applicazioni supportate da Supabase, la sicurezza dei dati si basa sulla sicurezza a livello di riga (RLS). Se RLS non è abilitato e configurato esplicitamente con criteri, qualsiasi utente con la chiave pubblica anonima può leggere, aggiornare o eliminare i dati nell'intero database. Ciò è particolarmente critico negli ambienti Next.js in cui il client Supabase viene spesso inizializzato con una chiave pubblica API.

CWE-284

Impatto

La mancata implementazione della sicurezza a livello di riga (RLS) consente agli aggressori non autenticati di eseguire query sui dati da un database Supabase quando le tabelle pubbliche vengono esposte attraverso il confine anonimo [S1]. Poiché le applicazioni Next.js in genere espongono la chiave Supabase anon nel codice lato client, un utente malintenzionato può utilizzare questa chiave per effettuare chiamate REST API dirette al database, ignorando la logica dell'applicazione prevista e accedendo alle informazioni sensibili dell'utente [S2].

Causa principale

Per impostazione predefinita, le tabelle Postgres in Supabase richiedono l'attivazione esplicita della sicurezza a livello di riga per impedire l'accesso pubblico [S1]. Quando uno sviluppatore crea una tabella ma dimentica di abilitare RLS o non riesce a definire policy restrittive, il database può esporre i dati a chiunque possieda la chiave anon [S1]. Nelle applicazioni Next.js, il rendering lato server e il recupero lato client richiedono anche un'attenta configurazione del client Supabase in modo che il contesto utente autenticato raggiunga il livello del database [S2].

Correzioni concrete

  • Abilita RLS: esegui ALTER TABLE "your_table_name" ENABLE ROW LEVEL SECURITY; per ogni tabella pubblica che memorizza i dati dell'app [S1].
  • Definisci policy: crea policy specifiche che limitano l'accesso in base allo stato di autenticazione dell'utente, ad esempio CREATE POLICY "Users can see their own data" ON your_table_name FOR SELECT USING (auth.uid() = user_id); [S1].
  • Proteggere i client lato server: quando si utilizza Next.js, mantenere i client con ruolo di servizio solo server e applicare comunque i filtri di proprietà prima di restituire i dati agli utenti [S2].

Come lo esegue il test FixVibe

FixVibe esegue già un controllo Supabase di sola lettura RLS tramite baas.supabase-rls. Lo scanner rileva l'URL del progetto Supabase e la chiave anon pubblica dai bundle JavaScript della stessa origine, richiede a PostgREST i metadati della tabella pubblica e tenta selezioni limitate di sola lettura per confermare se i dati vengono esposti senza una sessione utente. Non inserisce, aggiorna, elimina o utilizza le credenziali del ruolo del servizio. Le scansioni del repository possono anche individuare questo problema in precedenza tramite repo.supabase.missing-rls, che contrassegna le migrazioni SQL che creano tabelle pubbliche senza ENABLE ROW LEVEL SECURITY.