Una checklist per la RLS di Supabase

Supabase rende banale creare un database e parlarci direttamente dal browser. È questo il suo fascino, ed è anche il rischio. Il client ha in mano una chiave, quindi è il database stesso che deve saper dire di no.

I controlli sono meccanici. La row level security è attiva su ogni tabella dello schema pubblico, comprese quelle aggiunte la settimana scorsa? Ogni tabella ha una policy esplicita, invece di ereditare un default permissivo? Le policy sono scritte sull’utente autenticato e non su una colonna che il client può impostare? Le chiavi service role restano solo nel codice lato server? Un utente può leggere la riga di qualcun altro cambiando un id nella richiesta?

Facciamo questa lista prima di ogni altra cosa in un recupero, perché una sola policy mancante di solito significa che ogni record di quella tabella era leggibile da chiunque abbia pensato di guardare. È l’audit più economico del software e il più costoso da saltare.