La tua app Supabase è sicura?

Supabase ti dà un vero database Postgres con un'API già davanti, ed è per questo che un'app può parlare con dati reali venti minuti dopo che hai iniziato. Ciò che sorprende le persone più tardi è che quella stessa API è raggiungibile da chiunque, da ovunque, con credenziali stampate dentro la tua app.

Ecco il punto che guida dopo guida racconta male: non è un difetto, e nasconderlo non è la soluzione. Supabase è progettato per essere interrogato direttamente da un browser. La protezione è sempre stata pensata per vivere altrove, e sapere dove è quasi tutto ciò che c'è da sapere per far girare un'app Supabase in tranquillità.

Perché il tuo database sta su internet di proposito

Perché la tua app ci parla dal browser del tuo visitatore, non da un server che gestisci tu.

Pensala come un negozio. La tua app è la vetrina, consegnata per intero a ogni visitatore. Il tuo database è il magazzino, e con Supabase il magazzino ha deliberatamente una porta propria sulla strada, così che la tua vetrina possa rifornirsi senza un servizio di consegna in mezzo. È quella porta a risparmiarti la scrittura di un backend.

Il che significa che la porta è pubblica, e il suo indirizzo è nella tua app perché la tua app deve bussarci. Non esiste un assetto in cui quell'indirizzo resti segreto. Quindi la domanda non è mai stata «degli estranei possono raggiungere il mio database». Possono, per costruzione. La domanda è che cosa consegna loro quando chiedono.

La chiave Supabase nella mia app dovrebbe starci?

Una delle due sì. L'altra mai, e si somigliano quasi in tutto.

La chiave pubblicabile (sb_publishable_… nei progetti nuovi, anon in quelli più vecchi) dice a quale progetto appartiene una richiesta. Non porta privilegi propri, ed è per questo che la documentazione di Supabase la descrive come sicura da includere in pagine web e app mobili. Trovarla nella tua app non è un problema.

La chiave segreta, sb_secret_… o la più vecchia service_role, è l'opposto. Aggira del tutto le tue regole e legge e scrive ogni riga di ogni tabella, da ovunque. Il suo posto è un server, una edge function, un worker: nessun luogo che un browser possa raggiungere.

Stanno una accanto all'altra sulla stessa pagina del pannello e hanno la stessa forma. Se una è mai finita incollata nel codice frontend, rigenerala nel pannello prima di modificare qualsiasi cosa, perché cancellare la riga non chiude la porta.

Quella pagina è Settings, poi API Keys, e contiene quattro valori invece di due.

L'impostazione che decide che cosa consegna la porta

La Row Level Security: un interruttore per tabella che decide, riga per riga, chi può leggere cosa. È l'intera ragione per cui una chiave pubblicabile è sicura.

Spenta, quella chiave restituisce l'intera tabella a chiunque la chieda. Accesa e con una policy scritta, è il database stesso a filtrare ogni richiesta, comprese le richieste che non sono mai passate dalla tua app.

Due dettagli decidono se ce l'hai davvero, e nessuno dei due è visibile dalla tua app:

Come è stata creata la tabella. Supabase attiva la Row Level Security in automatico per le tabelle fatte nel Table Editor del pannello. Le tabelle create eseguendo SQL non la ricevono e vanno attivate deliberatamente. File di migrazione, script e schemi generati dall'IA creano tutti le tabelle eseguendo SQL, quindi un progetto costruito così può avere una fila di tabelle non protette che sembrano esattamente uguali a quelle protette.

Che cosa dice la policy. Attiva vuol dire chiusa finché una policy non la apre. Una policy che permette a tutti la spalanca mentre il pannello continua a riportare la tabella come avente la Row Level Security attiva, lo stato che sembra protetto e non lo è.

Lo storage è ancora un'altra cosa. Un bucket pubblico è elencabile e scaricabile da chiunque abbia l'indirizzo del tuo progetto, qualunque cosa dicano le regole delle tue tabelle.

Come controllare il tuo progetto Supabase in una decina di minuti

Authentication → Policies. Leggi tutto l'elenco. Qualsiasi tabella che mostri la Row Level Security come disattivata è leggibile da chiunque. Per quelle che la mostrano attiva, apri la policy e leggi che cosa permette davvero.

Settings → API. Conferma che la chiave che la tua app spedisce sia quella pubblicabile. Se una chiave segreta è mai stata nel codice frontend, rigenerala qui per prima cosa. Se la tua dashboard mostra chiavi che iniziano con sb_publishable_ e sb_secret_ invece di anon e service_role, quello è il formato più recente, e la stessa regola decide quale delle due va nella tua app.

Storage → Buckets. Controlla quali sono pubblici e se è ciò che intendevi per i file al loro interno.

E poi guarda da fuori. Tutto quanto sopra è ciò che il tuo pannello dichiara configurato. Che cosa ottenga davvero una richiesta anonima è un'altra domanda, ed è quella a cui risponde la nostra scansione gratuita: interroga come farebbe un estraneo, senza leggere nessuna delle tue righe, e ti dà un voto in una ventina di secondi: controlla che cosa espone la tua app.

Apri Authentication → Policies e scorri l'elenco una volta. Le tabelle contrassegnate come disattivate sono quelle da cui partire, e se preferisci attraversare tutta la superficie come un elenco, la checklist di sicurezza in 10 minuti ne è la versione breve. Qualunque cosa tu trovi, sapere di poter rimettere i dati al loro posto conta quanto chiuderli a chiave, e dipende interamente da che cosa stai salvando.

Se preferisci che non dipenda dal tuo ricordartene, ecco come funzionano i backup automatici di Supabase.