Basi della sicurezza
Cos'è Supabase? Il database che ha scelto il tuo builder
Cos'è Supabase: il database, il login e l'archivio file dietro la tua app. Supabase manda avanti i server; le regole su chi legge le tue righe sono tue.

In breve
- Cos'è Supabase? È dove la tua app tiene tutto quello che deve ricordare: i tuoi utenti e le loro password, le righe dietro ogni elenco e i file che la gente carica.
- Quasi di sicuro lo ha scelto il tuo builder mentre creava il progetto, ed è per questo che nessuno ti ha mai fatto vedere cosa ci sta dentro.
- Supabase manda avanti le macchine. Le regole su chi può leggere quali righe sono tue, e su una tabella creata in SQL partono spente.
La tua app funziona. Da qualche parte nelle sue impostazioni, in una mail su una fattura o in mezzo a un messaggio di Lovable, c'è la parola Supabase. Prima o poi devi scoprire cos'è, e il motivo raramente è la curiosità: una scansione ha nominato il tuo progetto Supabase, uno sviluppatore ha chiesto che piano hai, oppure la tua app ha smesso di salvare e la risposta sta lì dentro.
Allora: cos'è Supabase. Ogni altra spiegazione risponde come se fosse una scelta tra strumenti, che è la domanda che si fa uno sviluppatore prima di iniziare un progetto. Tu quella scelta non l'hai mai fatta. L'ha fatta il tuo builder nei secondi che ci sono voluti per creare il progetto, ed è per questo che nessuno ti ha mai accompagnato dentro la cosa che adesso tiene tutti i dati dei tuoi utenti.
Questa è la versione per chi ce l'ha già.
Cos'è Supabase, in una frase?
È dove la tua app tiene tutto quello che deve ricordare.
I tuoi utenti e le loro password. Le righe dietro ogni elenco che la tua app mostra. Le immagini e i documenti che la gente carica. Quando qualcuno si registra alle due di notte, quella riga finisce nel tuo progetto Supabase e c'è ancora dopo che la scheda del browser si è chiusa.
Sotto c'è Postgres, un database in uso in produzione dagli anni novanta che non ti riserverà sorprese. Quello che Supabase aggiunge è tutto il contorno: un sistema di login, un posto per i file e un modo per far chiedere i dati alla tua app direttamente dal browser senza che tu scriva un server.
È su quest'ultimo punto che cominciano le tue decisioni.
I quattro pezzi che hai davvero
Quattro, e la tua app ne sta probabilmente usando almeno due.
- Il database. Tabelle di righe: i tuoi utenti, i tuoi ordini, i tuoi post. La parte che la gente intende quando dice "Supabase".
- Auth. Registrarsi, entrare, reimpostare una password. Se la tua app ha degli account, stanno qui.
- Storage. I file caricati, in bucket con un nome. Foto profilo, allegati, esportazioni.
- Edge functions. Piccoli pezzi di codice che girano sui server di Supabase invece che nel browser del tuo visitatore. La tua app potrebbe non averne nessuna, e c'è comunque un buon motivo per interessarsene, più sotto.
La tua dashboard ne elenca più di quattro. Lascia stare il resto finché quello che stai costruendo non ne ha bisogno.
Di cosa si occupa Supabase e cosa è mio?
Supabase si occupa delle macchine. Tu ti occupi delle regole.
La linea sta più in alto di quanto quasi tutti immaginino. Pensa al progetto come a dei locali in affitto. Il proprietario mantiene l'edificio, la corrente e il portone. Cosa tieni dentro, e chi fai entrare, non è mai stato lui a deciderlo.
| Cosa manda avanti Supabase | Cosa è tuo |
|---|---|
| I server, la versione di Postgres e gli aggiornamenti | Quali righe ogni visitatore ha il permesso di leggere |
| Backup giornalieri del tuo database sui piani a pagamento, tenuti per una settimana | Se esiste una copia da qualche parte dove il tuo stesso progetto non arriva |
| Cifrare i tuoi dati sui suoi dischi e lungo la strada verso la tua app | Chi ha le tue chiavi e quale di esse sta nella tua app |
| Tenere in piedi il sistema di login | Quali file di un bucket chiunque può elencare |
Niente nella colonna di sinistra si rompe in silenzio: se Supabase ha un disservizio, lo senti dai tuoi utenti nel giro di minuti. La colonna di destra è quella dove le cose vanno storte senza un rumore, perché non si rompe niente. La tua app va avanti esattamente come ieri.
I miei dati su Supabase sono privati per impostazione predefinita?
Dipende da come è stata creata ogni tabella, e il modo in cui le crea un builder è quello che le lascia aperte.
La documentazione di Supabase è diretta su questo. Dice che il Table Editor attiva Row Level Security al posto tuo quando crei una tabella nel Dashboard, e che quando crei una tabella in SQL la attivi tu. Row Level Security è l'impostazione per singola tabella che decide quali righe un visitatore può leggere. Il tuo builder scrive SQL, quindi una tabella creata dal tuo builder arriva con quell'impostazione spenta.
La frase successiva della stessa pagina dice cosa lascia dietro: una tabella
nello schema public è raggiungibile tramite la Data API, e finché non attivi
Row Level Security e scrivi una policy, chiunque abbia la chiave publishable del
tuo progetto può leggere e scrivere tutte le sue righe. Quella chiave sta nella
tua app, dove le spetta, e chiunque può leggerla dalla pagina.
Quindi la serratura di ogni tabella è la cosa da andare a guardare, e sta per tabella invece che per progetto. Come attivarla, e cos'è una policy è la guida passo passo. Abbiamo anche contato quanto spesso manca: 2.096 delle 3.680 app il cui database Supabase ci ha risposto avevano almeno una tabella che consegnava le sue righe a uno sconosciuto.
Se preferisci vederlo da fuori invece di scorrere un elenco di tabelle, la nostra scansione gratuita fa al tuo progetto la domanda che farebbe il browser di uno sconosciuto e ti mostra cosa è tornato indietro. Ci vogliono circa 20 secondi e non serve un account: scansiona la tua app gratis.
Dove stanno le tue chiavi e quale è pubblica
La tua pagina delle impostazioni API contiene valori di due tipi, e solo un tipo va nella tua app.
Una chiave che comincia con sb_publishable_, chiamata anon in un progetto
più vecchio, è pensata per essere pubblica e da sola non fa altro che dire a
quale progetto appartiene una richiesta. Una chiave che comincia con
sb_secret_, chiamata service_role in un progetto più vecchio, passa oltre
ogni regola che imposti. Supabase lo dice chiaramente: una chiave segreta
aggira Row Level Security, quindi va tenuta lato server. Questo è anche il buon
motivo per interessarsi alle edge functions, perché una function è il posto dove
il lavoro che ha bisogno di una chiave segreta può avvenire senza che la chiave
si avvicini a un browser.
Dov'è quella pagina e cosa fa ogni valore copre i posti, e quali chiavi sono sicure nel frontend copre come distinguere due chiavi quasi identiche.
Come resta tuo dopo la pubblicazione
Quello che trovi oggi descrive l'app di oggi. La prossima tabella che aggiunge il tuo builder arriva con la stessa impostazione predefinita della precedente, e nessuno ti manda un messaggio al riguardo.
Reeve Monitor rifà le domande di questo articolo, a intervalli regolari:
- tutti e nove i controlli ogni ora, su un massimo di tre app
- se l'app risponde, ogni 60 secondi
- un messaggio quando un risultato cambia, così una tabella che si è aperta stanotte arriva a te prima che a uno sconosciuto
- un report mensile di quello che ha visto
Reeve Care tiene anche una copia del tuo database Supabase. È la seconda riga della colonna di destra qui sopra, fatta per te.
- una copia cifrata del tuo database Supabase ogni notte, tenuta dove il tuo progetto non arriva
- ogni copia verificata prima di valere, contando le righe di ogni tabella
- un ripristino con un clic quando ti serve
- anche i tuoi file caricati, appena colleghi una credenziale Storage
- tutto quello che fa Monitor
Una tabella che uno sconosciuto può leggere è una cosa che un controllo trova. Una migrazione andata al contrario, o un agente con accesso al tuo database, svuota la tabella invece, ed ecco come si vede da dentro.
Cosa controllare una volta, oggi
Cosa fare
- Entra in Supabase e apri il tuo progetto. L'account è tuo anche se lo ha creato il tuo builder, ed è nella dashboard che sta ognuna delle risposte qui sotto.
- Leggi la serratura di ogni tabella in Authentication → Policies. Una tabella con Row Level Security disattivato consegna le sue righe a chiunque abbia la chiave che sta già nella tua app, e una policy che permette tutto a tutti conta come disattivata.
- Apri Settings → API Keys e scopri quali dei tuoi valori sono publishable e quali secret. Se una chiave segreta è mai stata nella tua app, sostituiscila su Supabase prima di toglierla dal codice.
- Guarda i tuoi bucket di storage. Un bucket segnato come pubblico elenca ogni file che contiene a chiunque lo chieda, compresi quelli che la tua app non mostra mai.
- Tieni una copia del database da qualche parte dove il tuo progetto non arriva, perché niente dell'elenco qui sopra riporta indietro una tabella cancellata.
Comincia dalle serrature delle tabelle, perché è l'unica voce di questo elenco che uno sconosciuto può già stare usando. Se preferisci affrontare tutto come un elenco, la checklist di sicurezza in 10 minuti copre questo e le altre impostazioni che vale la pena leggere su un'app appena pubblicata. Supabase è sicuro? affronta l'altra domanda con cui la gente arriva, cioè se tutto questo sia stata una buona idea.
FAQ
Cos'è Supabase in parole semplici?
È dove la tua app tiene tutto quello che deve ricordare, su server di cui si occupa qualcun altro. I tuoi utenti e le loro password, le righe dietro ogni elenco che la tua app mostra e i file che la gente carica stanno tutti nel tuo progetto Supabase. È costruito su Postgres, un database in uso in produzione dagli anni novanta, con intorno un sistema di login, un archivio file e un modo per far chiedere i dati alla tua app direttamente dal browser.
Supabase è un database?
Ne contiene uno, ed è più di uno. Il database è Postgres ed è la parte che la gente intende quando dice Supabase. Intorno ci sono altri tre servizi che la tua app forse sta usando: Auth per far entrare le persone, Storage per i file caricati e Edge Functions per il codice che gira sui server di Supabase invece che nel browser del tuo visitatore. La tua dashboard ne elenca più di quattro, e il resto puoi lasciarlo stare finché non ti serve.
È stato il builder della mia app a scegliere Supabase?
Quasi di sicuro sì. Lovable, Bolt, v0, Cursor, Replit e Windsurf ricorrono tutti a un Postgres gestito nel momento in cui la tua app deve ricordare qualcosa, e Supabase è la risposta più comune. Forse hai premuto un pulsante con scritto collega un database, oppure il tuo builder ha creato il progetto senza chiedere. In ogni caso l'account è tuo e puoi entrarci, ed è la prima cosa che vale la pena fare.
Quali parti della sicurezza di Supabase sono compito mio?
Supabase manda avanti i server, la versione di Postgres, gli aggiornamenti, la cifratura sui suoi dischi e il sistema di login stesso. Tue sono le regole: quali righe può leggere ogni visitatore, quali file di un bucket sono pubblici, chi ha le tue chiavi e quale di esse sta nella tua app, e se esiste una copia dei tuoi dati da qualche parte dove il tuo progetto non arriva. Niente del primo elenco si rompe in silenzio. Tutto quello del secondo può restare sbagliato per mesi mentre la tua app funziona benissimo.
I miei dati su Supabase sono privati per impostazione predefinita?
Dipende da come è stata creata ogni tabella. La documentazione di Supabase dice che il Table Editor attiva Row Level Security al posto tuo quando crei una tabella nel Dashboard, e che quando crei una tabella in SQL la attivi tu. Un builder scrive SQL, quindi le tabelle che ha creato per te arrivano con quell'impostazione spenta. Finché resta spenta e non c'è una policy scritta, Supabase dice che chiunque abbia la tua chiave publishable può leggere e scrivere tutte le righe di quella tabella, e quella chiave sta nella tua app, dove chiunque può leggerla.