Supabase "RLS disabled in public": cosa non vede l'avviso

Hai aperto il Security Advisor nella tua dashboard Supabase, oppure qualcuno ti ha messo davanti il suo output, ed eccolo lì in rosso: RLS disabled in public. Sotto, una riga per tabella, con le parole di Supabase:

Table public.profiles is public, but RLS has not been enabled.

Ecco la parte che guida dopo guida racconta male: svuotare quella lista non vuol dire che nessuno possa leggere i tuoi dati. L'advisor ha una regola a parte per una policy che fa entrare tutti, e quella regola salta esattamente la forma che un costruttore di IA scrive quando rimette in piedi la tua app. Così la lista che hai appena sistemato e la lista delle tabelle che uno sconosciuto può leggere sono due liste diverse, e una delle due non è scritta da nessuna parte nella tua dashboard.

Cosa vuol dire "RLS disabled in public"?

Una tabella del tuo schema public ha Row Level Security spento, e la conseguenza è che chiunque abbia l'indirizzo del tuo progetto può leggerne ogni riga.

Entrambe le metà vanno aperte. Lo schema public è il posto dove una tabella finisce quando nessuno dice altrimenti, ed è la parte del tuo database che Supabase pubblica sul web: ogni progetto risponde alle richieste a un indirizzo suo, e la chiave che serve per parlargli sta nel codice che il tuo sito manda a ogni visitatore. Row Level Security è l'interruttore che decide se le tue regole vengono consultate prima che le righe escano. Spento, non c'è nulla da consultare, quindi la risposta è sempre sì.

È questa combinazione che fa segnalare la cosa come errore e non come avviso. L'advisor classifica quello che trova, e questo è il gradino più alto.

Pensa all'advisor come a un ispettore con una cartellina. Legge le tue carte con attenzione ed è bravo a farlo. Non prova mai la maniglia. Niente in quel pannello è il risultato di una richiesta che qualcuno abbia fatto al tuo database.

Attivare RLS romperà la mia app?

Sì, subito, ed è l'impostazione che funziona.

La correzione che Supabase ti dà è una riga, e la esegui nel SQL Editor:

alter table public.profiles enable row level security;

La documentazione di Supabase è chiara su cosa succede dopo: con una chiave pubblicabile i dati diventano irraggiungibili dall'API finché non sono definite delle policy. Le tue liste tornano vuote, le schermate restano bianche, e l'errore nell'advisor viene sostituito da una voce più discreta che dice che la tabella ha RLS attivo ma nessuna policy.

Questa è la porta chiusa con ancora nessuno sulla lista. La cosa che quasi tutti fanno dopo è aggiungere una policy che fa leggere tutti, perché è quella che fa tornare le schermate.

Il guasto che l'avviso non sta cercando

Una tabella con Row Level Security acceso e una policy di lettura la cui condizione è USING (true) consegna esattamente le stesse righe esattamente allo stesso sconosciuto. L'advisor non la segnala.

Non è una svista. Supabase una regola per le policy sempre vere ce l'ha, e lascia fuori quelle di lettura di proposito. La sua stessa descrizione della regola lo dice:

SELECT policies with `USING (true)` are intentionally excluded as this
pattern is often used deliberately for public read access.

Nel caso generale la regola ha ragione. Un catalogo prodotti, un elenco di articoli pubblicati, una mappa di locali: quelli sono fatti per essere letti da chiunque, e segnalarli abituerebbe ogni sviluppatore sulla piattaforma a ignorare il pannello. Quello che nessun linter può sapere è se la tabella che ha davanti contiene locali o clienti.

E una policy che fa leggere tutti è il modo più rapido di rimettere in piedi un'app rotta, ed è per questo che un costruttore di IA ci si appoggia. Chiedi a Cursor o a Lovable di sistemare le schermate vuote e FOR SELECT USING (true) è una risposta frequente. La tua app carica, l'errore sparisce, il pannello tace, e la tabella si legge come prima.

Le due righe dove non viene segnalato niente sono la coppia su cui vale la pena fermarsi. Una è una tabella che fuori dalla tua app nessuno può toccare. L'altra è una tabella che chiunque può leggere. La tua dashboard tace allo stesso modo su entrambe.

Come quella policy sia stata scritta, e con cosa sostituirla tabella per tabella, è l'argomento di Row Level Security è attivo e la tabella resta pubblica. Se la stessa policy deve anche lasciar salvare la tua app, l'errore che incontri subito dopo è new row violates row-level security policy.

Perché la tabella creata con una migrazione non ti ha mai avvisato

Perché il Table Editor accende Row Level Security al posto tuo e SQL no.

Supabase documenta la differenza senza giri di parole: le tabelle create con il Table Editor della dashboard hanno RLS attivo per impostazione predefinita, e quelle create con SQL grezzo vanno attivate in modo esplicito. Una tabella nata a forza di clic parte protetta. Una tabella arrivata da un file di migrazione, un supabase db push, uno snippet nel SQL Editor o un'istruzione che il tuo costruttore di IA ha eseguito per te parte aperta.

Quella seconda strada è come un costruttore di IA crea le tabelle. Scrive il SQL e lo esegue per te, quindi la casella non l'hai mai vista e non l'hai mai vista senza spunta.

L'abitudine che chiude la faccenda è mettere la riga nella migrazione, accanto alla cosa che protegge:

create table public.profiles (
  id uuid primary key references auth.users,
  full_name text
);

alter table public.profiles enable row level security;

Come controllare le tabelle che l'advisor ha lasciato passare

Fai al tuo database la domanda che fa uno sconosciuto: manda una richiesta da fuori, con la chiave pubblicabile che viaggia dentro la tua app, e guarda cosa torna indietro.

È la differenza attorno a cui gira tutto l'articolo. L'advisor legge la tua configurazione. Una richiesta legge le tue righe. Sono due domande diverse, e una tabella può passare la prima e fallire la seconda, che è esattamente quello che fa una policy di lettura permissiva.

Quella richiesta l'abbiamo fatta su larga scala. Fra il 12 e il 14 agosto 2026 abbiamo passato nove controlli esterni su 30.998 app in produzione pubblicate da Lovable, Base44, Replit, v0 e Bolt. Delle 3.680 app con Supabase dove il controllo è arrivato in fondo, 2.096 avevano almeno una tabella che a una richiesta anonima ha risposto con delle righe. Fa 57%, ed è una quota delle app da cui siamo riusciti a ottenere una risposta netta, non di tutto quello che abbiamo scansionato. Fra le app fatte con Bolt sono state 27 su 35, un campione abbastanza piccolo da leggersi come una direzione e non come un tasso. L'intero dataset è pubblicato, e di cosa è una quota quel 57% ripercorre il conteggio.

Quella stessa richiesta puoi farla tu su una tabella con un browser e la tua chiave pubblicabile. Se preferisci non andare tabella per tabella, la nostra scansione gratuita interroga la tua app dal vivo da fuori e ti dice quali tabelle hanno risposto. Ci mette una ventina di secondi e non chiede un account: scansiona la tua app.

Mi serve un backup prima di cambiare le policy RLS?

Per ogni tabella su cui la tua app scrive, sì. Per una tabella di sola lettura che stai soltanto stringendo, il rischio è che la tua app resti bianca, non che spariscano dei dati.

Qui conviene separare due cose diverse, perché solo una riguarda la riparazione.

Cosa ha già permesso una policy permissiva. Se la regola sulla tabella era FOR ALL USING (true) e non FOR SELECT, allora chi l'ha trovata poteva cambiare e cancellare righe oltre che leggerle, e stringerla oggi non fa nulla riguardo a ieri. Quella versione di solito viene fuori come un messaggio all'assistenza su dati che sono cambiati da soli, o come una tabella improvvisamente vuota.

La riparazione in sé. Riscrivere le policy su una dozzina di tabelle è una modifica a un database in produzione, scritta dagli stessi strumenti che hanno prodotto il problema. Una migrazione che elimina una policy e la ricrea storta è un martedì qualunque, e la strada del ritorno è una copia di com'erano le cose un'ora fa.

Su un piano Supabase a pagamento la copia di ieri sera è lì nella console. Sul piano gratuito non c'è nulla su cui ripiegare, perché il piano gratuito non fa alcun backup automatico. Se è il tuo caso, prendine una prima di toccare una policy: come fare il backup di un database Supabase sul piano gratuito è la versione da dieci minuti.

Di cosa Reeve Care tiene una copia

Del tuo database Supabase, copiato su una pianificazione, tenuto fuori dal tuo account Supabase, cifrato e riletto prima che la data sulla tua dashboard si muova. I file che i tuoi utenti hanno caricato viaggiano insieme a lui appena colleghi una chiave Storage.

Due limiti, detti prima. I backup sono solo per Supabase: se i tuoi dati stanno altrove lo diciamo, invece di venderti un abbonamento che sorveglia una scatola vuota. E la chiave Storage viene chiesta a parte, perché Supabase non emette una chiave di sola lettura per i file, quindi quella che copia i tuoi caricamenti può anche scrivere. Quella che copia il tuo database non può. Collegarla è facoltativo, e il database viene salvato comunque.

Il ripristino è la parte che conta per questo articolo. Rimettere una copia vecchia sopra un database in produzione è il pulsante che fa più paura del prodotto, così Care prende prima una copia dello stato attuale e solo dopo riproduce quella che hai scelto. Il ripristino ha un annulla tutto suo.

L'altra metà di Care è quella verso cui questo articolo continua a puntare. Una policy che si è allentata durante una migrazione non è una cosa che trovi guardando, così lo stesso controllo esterno riparte su una pianificazione e ti avvisa quando la risposta cambia. Uptime, un report mensile e la scansione stanno nello stesso abbonamento.

Quello che una copia non fa è scriverti le policy, e nessun backup rende chiusa una tabella aperta. Quelle tabelle restano roba tua. Quello che la copia cambia è cosa succede quando la riparazione va storta. Cosa salva Reeve su Supabase, ogni quanto, e cosa fa un ripristino disegna il ciclo intero, e i piani con i loro prezzi stanno sulla pagina prezzi.

Cosa fare questa settimana

Parti dalla tabella che come pagina pubblica ti imbarazzerebbe di più. La checklist di sicurezza in 10 minuti copre questo insieme al resto di quello che vale la pena verificare in un'app appena lanciata, e la guida alla sicurezza di Supabase passa in rassegna cos'altro tende a restare aperto.