Attivare RLS non basta a sapere se i permessi sono corretti. Verifichiamo quali dati ogni utente può leggere o modificare, anche passando da funzioni, viste e codice server.
Scriviamo chi può fare cosa
Prepariamo un elenco di risorse e operazioni consentite a visitatori, utenti, membri del team e amministratori. Queste regole servono per confrontare ciò che il prodotto deve permettere con ciò che permette davvero.
- Dati personali e risorse condivise
- Inviti, ruoli e appartenenza a organizzazioni
- Operazioni amministrative e processi server
Esaminiamo policy e altri accessi ai dati
Controlliamo grants, RLS, viste e funzioni esposte. Distinguiamo le chiavi pubblicabili dalle credenziali riservate e verifichiamo dove sono usate. Includiamo Storage e accessi dal backend quando fanno parte del progetto.
Proviamo account con permessi diversi
Uso account e dati di prova in un ambiente concordato. Verifichiamo che le operazioni consentite riescano e quelle vietate vengano bloccate. Dopo una modifica alle policy, ripetiamo i casi coinvolti.
Indichiamo cosa ricontrollare nelle prossime versioni
Aggiungere una tabella o una funzione può cambiare chi accede ai dati. Ti lasciamo casi da ripetere dopo le migrazioni, considerando anche le query che potrebbero rallentare a causa delle policy.
Prima di iniziare
Basta abilitare RLS per proteggere i dati?
Abilitare RLS non dimostra che le policy rispettino le regole del prodotto. Verifichiamo anche ruoli, operazioni consentite e percorsi di accesso attraverso funzioni e codice server, usando gli account di prova concordati.
Devo inviarvi la service role key?
Non nel form o nel primo messaggio. Definiamo prima attività e accessi necessari; eventuali credenziali vengono gestite con una procedura concordata e privilegi limitati al lavoro.
Aggiornato il