Supabase RLS: audit manuale o scansione?

Row Level Security è la linea tra un progetto Supabase che protegge i suoi dati e uno che li espone silenziosamente. Quando RLS è configurato correttamente, il database applica le regole di accesso a livello di riga, per i ruoli soggetti a RLS. I ruoli privilegiati, incluso il ruolo del servizio, possono ignorare tali regole. Quando è configurato in modo inadeguato, le tabelle sembrano protette mentre le policy lasciano passare più di quanto previsto.

Questo articolo mette a confronto due modi per eseguire un controllo di sicurezza Supabase RLS: verifica manuale delle policy ed esecuzione di un controllo RLS automatizzato. Entrambi hanno un posto. Sapere dove ciascuno di essi si interrompe è il modo in cui verifichi che i criteri di accesso al database funzionino come previsto.

RLS è una funzionalità Postgres che Supabase espone per tabella. Una volta abilitata, una tabella nega l'accesso alle righe ai ruoli soggetti a RLS a meno che una policy non lo consenta; i proprietari di tabelle e i ruoli con privilegi di esclusione costituiscono eccezioni. Le policy vengono valutate rispetto all'utente corrente, alle sue attestazioni e alla query in esecuzione. Il auth.uid() la funzione è solitamente l'ancora: una politica simile using (auth.uid() = user_id) limita l'accesso alle righe del database dell'utente che ha effettuato l'accesso.

Il modello è pulito. I fallimenti non lo sono, perché raramente sembrano fallimenti.

Alcuni modelli rappresentano la maggior parte dei problemi RLS:

• RLS abilitato su alcuni tavoli, non su tutti. Una nuova tabella aggiunta dopo il lancio o creata tramite una migrazione può essere spedita con RLS disattivato. Ogni riga è quindi leggibile da qualsiasi ruolo con accesso alla tabella.

• Una politica più ampia di quanto si possa leggere. using (true) su una policy selezionata significa che ogni riga è visibile. È facile aggiungerlo durante lo sviluppo per il debug e dimenticarsi di rimuoverlo.

• Il ruolo di servizio assunto ovunque. Il codice lato server che utilizza la chiave del ruolo del servizio ignora completamente RLS. Se le richieste rivolte agli utenti passano attraverso quella chiave, le policy non si applicano mai.

• Politiche che controllano la colonna sbagliata. auth.uid() = id su un tavolo dove id è la chiave primaria della riga, non il proprietario, non corrisponderà mai all'intento. La policy esiste, restituisce un errore o un set vuoto e la superficie funziona ancora.

• Aggiornamenti ed eliminazioni del database senza controlli di accesso adeguati. Gli sviluppatori spesso garantiscono una selezione accurata e lasciano libere le politiche di scrittura. Il superamento di un controllo di lettura non dice nulla su chi può modificare la riga successiva.

Nessuno di questi si annuncia. Ognuno di essi mantiene l'app funzionante, motivo per cui sopravvivono fino alla produzione.

Un audit manuale è diretto e non richiede nuovi strumenti. Si lavora attraverso le politiche stesse, tabella per tabella.

Inizia elencando tutte le tabelle e confermando che RLS è abilitato su ciascuna di esse. Quindi, per ciascuna tabella, enumerare le policy e mapparle in base all'accesso previsto: chi dovrebbe leggere, chi dovrebbe scrivere e chi non dovrebbe mai toccarlo. Leggi ogni espressione di policy rispetto alla colonna che confronta. Confermare che i criteri di selezione, inserimento, aggiornamento ed eliminazione dispongano di una policy che corrisponda al ruolo previsto.

Successivamente, controlla il percorso del codice. Determina quale chiave utilizza effettivamente la tua applicazione per le richieste rivolte agli utenti e se qualcuna di esse viene eseguita tramite il ruolo del servizio. Quindi scrivi query di prova come utenti diversi e conferma che i risultati corrispondono alle aspettative: un utente dovrebbe leggere le proprie righe e quelle di nessun altro e non dovrebbe essere in grado di aggiornare una riga che non possiede.

Vale la pena fare la revisione manuale e cattura molto. Ha anche punti ciechi prevedibili.

• Mette alla prova ciò che ricordi di testare. Se non pensi di provare un'eliminazione come secondo utente, potresti perdere una politica di eliminazione troppo ampia. Con RLS abilitato, nessuna policy di eliminazione applicabile significa che l'eliminazione viene negata.

• Invecchia. Le politiche si spostano man mano che vengono aggiunte funzionalità. Una revisione approfondita lo scorso trimestre non dice nulla sulla tabella aggiunta la settimana scorsa.

• Dipende dalla stessa persona che ha configurato le policy. Il costruttore che ha scritto la politica è quello che ha meno probabilità di individuare la propria ipotesi.

• Ha bisogno di prove registrate. "L'ho esaminato e sembrava corretto" non lascia nulla dietro: nessuna prova, nessun ambito, nessun artefatto che puoi scansionare nuovamente in seguito.

L'auditing manuale risponde alla domanda "questo corrisponde al mio modello mentale del sistema?" Di per sé non dimostra cosa verrà effettivamente restituito dal database.

Un controllo di sicurezza automatizzato Supabase RLS funziona dalla direzione opposta. Esercita il progetto come farebbe un utente malintenzionato o un client configurato in modo errato e segnala ciò che il livello dati consente effettivamente.

Questo cambiamento è importante per tre ragioni. Innanzitutto, supera la memoria: la scansione ripete i controlli sulle tabelle e sugli endpoint disponibili nell'ambito configurato. Una scansione esterna non può ispezionare ogni policy senza un accesso adeguato. In secondo luogo, produce prove su cui è possibile agire: la scoperta nomina la tabella, lo stato della politica e la condizione che l’ha resa raggiungibile, in modo da sapere cosa cambiare e perché. Terzo, è ripetibile. Un controllo che puoi eseguire nuovamente trasforma una revisione una tantum in una verifica continua.

VICE esegue la scansione delle applicazioni Web e delle configurazioni Supabase/RLS, quindi riporta i risultati con le prove a supporto e le indicazioni di correzione su cui lavorare. È possibile contrassegnare una correzione e richiedere un nuovo controllo, ma solo una nuova scansione comparabile conferma che il problema è stato risolto: la correzione viene verificata rispetto allo stesso ambito, non presupposta dalla modifica. Le scansioni e gli avvisi pianificati supportano il monitoraggio continuo, quindi una tabella aggiunta il mese prossimo non reintroduce silenziosamente il divario.

La divisione del lavoro è semplice. Esegui il controllo automatico per scoprire cosa è mancato durante la revisione manuale, quindi utilizza un passaggio manuale per confermare l'intento dietro ciascuna policy segnalata dalla scansione. L'automazione ti dice cosa consente il database; sei tu a decidere se tale permesso è stato intenzionale.

Un punteggio ottenuto da qualsiasi scansione descrive l'ambito testato, non una garanzia che un progetto sia completamente sicuro. Consideralo come un segnale di dove cercare, non come un certificato.

Se stai distribuendo un prodotto realizzato con Supabase e non hai mai verificato le tue policy, la risposta onesta è entrambe le cose, in ordine. Inizia con un controllo RLS automatizzato in modo da avere un quadro aggiornato e comprovato di ciò che le tue tabelle consentono. Quindi esamina manualmente i risultati, conferma l’intento di ciascuna politica e correggi quelle che sono andate alla deriva. Pianifica il controllo automatico in modo che le nuove tabelle e le nuove policy ricevano lo stesso controllo di quelle originali.

Saltare uno dei due approcci può lasciare una policy di accesso al database che sembra proteggere i dati ma consente comunque l'accesso non autorizzato.

Avvia una scansione gratuita su vice-platform.com per controllare il tuo sito web pubblico prima di registrarti. Una scansione Supabase specializzata richiede un dominio verificato e un abbonamento a pagamento o un credito acquistato; la sua copertura dipende dall'accesso configurato.