1. Verificare RLS su ogni tabella
La Row Level Security va controllata sulle singole tabelle. Elenca quelle raggiungibili dagli schemi esposti e verifica per ciascuna se RLS è attiva. In PostgreSQL, quando RLS è attiva e manca una policy applicabile, il normale accesso alle righe viene negato. Proprietari e ruoli privilegiati possono però comportarsi diversamente. Per questo una query eseguita dal pannello amministrativo non ti dice cosa può fare un cliente: ripeti la prova con il ruolo e la sessione usati dalil prodotto.
2. Controllare anche i grants
La documentazione Supabase distingue i privilegi sull'oggetto dalle regole sulle righe: i grants stabiliscono quali operazioni un ruolo può raggiungere; le policy RLS ne limitano le righe. Rivedili insieme, verificando la configurazione reale del progetto. Per preparare la review, crea una tabella di lavoro con risorsa, ruolo e operazioni necessarie. Un permesso che nessuno sa collegare a un requisito merita di essere approfondito, prima di aggiungere altre policy per far sparire un errore.
3. Distinguere chiavi pubblicabili e credenziali riservate
Supabase prevede chiavi publishable, destinate anche al client, e chiavi secret per contesti server controllati. Le chiavi legacy anon e service_role richiedono la stessa distinzione tra accesso pubblico e privilegiato. Una chiave pubblicabile visibile nel browser non è, da sola, una credenziale riservata esposta. Una secret o service_role deve invece restare fuori dal client. Verifica il tipo di chiave e il ruolo effettivo della richiesta, oltre al luogo in cui viene inizializzato il client.
4. Provare inserimenti e modifiche
Una policy deve rappresentare anche che cosa l'utente può inserire o cambiare. In PostgreSQL, USING riguarda le righe esistenti a cui l'operazione può accedere; WITH CHECK valuta la nuova riga prodotta da inserimenti o aggiornamenti. Prova quindi anche cambi di proprietario o organizzazione, con dati sintetici. Rivedi tutte le policy applicabili: quelle permissive possono combinarsi in OR, ampliando l'accesso. Una singola policy corretta non descrive necessariamente il risultato dell'insieme.
- Inserimento con un proprietario previsto e uno non consentito.
- Aggiornamento di una risorsa propria e di una risorsa altrui.
- Cambio di organizzazione o altro campo che determina l'accesso.
5. Controllare viste, funzioni e file
La guida Supabase sulla RLS richiama l'attenzione sulle viste, che possono usare privilegi diversi da quelli dell'utente chiamante. Esamina anche le funzioni e i percorsi server che usano credenziali privilegiate. I file hanno un altro punto di controllo: Supabase Storage usa policy su storage.objects per le operazioni protette, mentre la scelta di un bucket pubblico cambia l'accessibilità dei contenuti. Elenca ogni percorso con cui il prodotto legge o modifica una risorsa prima di concludere la verifica.
6. Usare account con ruoli diversi
Prepara alcuni account di prova: un visitatore senza login, due membri della stessa organizzazione con ruoli diversi e un utente di un’altra organizzazione. Scrivi per ciascuno quali operazioni devono riuscire e quali devono essere bloccate. Poi esegui i casi con le sessioni corrispondenti, in un ambiente autorizzato e con dati di prova. Controlla entrambi i risultati: se tutte le richieste vengono negate, i dati possono essere inaccessibili anche a chi dovrebbe usarli. Conserva queste prove per le prossime migrazioni.
- Ripeti i casi dopo una modifica di policy o una migrazione.
- Verifica lo stato della sessione usata nel test.
- Conserva la matrice accanto alle decisioni sul modello di accesso.