Supabase crittografa i miei dati? Sì. Ecco da cosa protegge

Un cliente ti scrive per chiederti se i suoi dati sono crittografati. Oppure un cliente più grande ti manda un questionario di sicurezza sotto forma di foglio di calcolo, e dentro ci sono le righe che ogni questionario ha: crittografia a riposo, crittografia in transito, il report SOC 2 del tuo provider di hosting. La tua app gira su Supabase perché Lovable o Bolt l'hanno impostata così, e finora nessuno aveva bisogno che tu sapessi cosa vuol dire tutto questo.

Quindi, Supabase crittografa i tuoi dati? Sì. Tutti, su ogni piano, e i certificati dietro questa affermazione sono veri.

La maggior parte delle risposte sbaglia fermandosi qui, come se la crittografia decidesse chi può leggere i tuoi dati. Decide qualcosa di più ristretto. Immagina Supabase come una banca. La crittografia a riposo è il caveau, la crittografia in transito è il furgone portavalori, e SOC 2 è l'ispettore che controlla che entrambi funzionino come dice la banca. Ognuno riguarda qualcuno che non doveva mai entrare. La regola allo sportello, cioè di chi un cliente può chiedere l'estratto conto, è un'altra cosa, e si scrive nel tuo progetto.

Ogni dato qui sotto è stato letto sulle pagine e nella documentazione di Supabase il 29 settembre 2026.

Supabase crittografa i miei dati?

Sì. La pagina sulla sicurezza di Supabase dice che tutti i dati dei clienti sono crittografati a riposo con AES-256 e in transito con TLS, e non devi attivare niente.

A riposo vuol dire sui dischi. Il tuo database viene scritto sullo storage in forma crittografata, quindi una copia del disco portata via dalle macchine di Supabase è illeggibile da sola.

In transito vuol dire lungo il tragitto tra il tuo visitatore e Supabase. La tua app parla con Supabase attraverso le sue API web, per i dati, gli accessi e i file, e la guida all'obbligo di SSL di Supabase dice che ognuna di queste API rifiuta una connessione non crittografata. L'eccezione è una connessione diretta al database Postgres sottostante, quella che può aprire uno strumento di backup o un tuo server. Quelle accettano una connessione non crittografata finché non attivi Enforce SSL on incoming connections in Database Settings. I browser dei tuoi visitatori non ne aprono mai una.

La crittografia delle colonne è l'unico livello che resta spento. Tiene un singolo valore, per esempio un numero di telefono, illeggibile anche dentro il database. Supabase documentava un modo per farlo, e la sua pagina su pgsodium ora sconsiglia quella funzione, citando la sua complessità operativa e il rischio di configurarla male, e aggiunge che la crittografia a riposo probabilmente basta per SOC 2 e HIPAA. Per i segreti come la chiave API di un servizio esterno c'è Vault, che li conserva crittografati e li restituisce attraverso una view.

Da cosa protegge la crittografia di Supabase?

Da chiunque arrivi ai tuoi dati senza chiederli al database. Chi si porta via un disco, copia un file di backup o ascolta il traffico tra un browser e Supabase ottiene byte rimescolati e nient'altro.

Una richiesta a cui il database decide di rispondere è un'altra faccenda. La crittografia a riposo lavora sotto Postgres, quindi il database legge i propri file in chiaro, per ogni query che serve. Quali query serve lo stabiliscono i permessi su ogni tabella. In Supabase è la Row Level Security, la regola che dice quali righe ogni visitatore può leggere, e ogni tabella deve averla attiva con una regola scritta per lei.

È lo sportello della banca. Il caveau si apre ogni volta per il cassiere, perché il cassiere lavora per la banca. Se nessuno ha scritto di chi un cliente può vedere gli estratti conto, il cassiere consegna quello che gli viene chiesto, e il furgone portavalori lo recapita, sigillato per tutto il tragitto, a chi l'ha chiesto.

La documentazione di Supabase dice la stessa cosa di Vault, che crittografa davvero valori dentro il database: "chiunque abbia accesso alla view ha accesso ai segreti decifrati."

La crittografia impedisce a uno sconosciuto di leggere le mie tabelle?

No, e abbiamo misurato quanto spesso conta. Ad agosto 2026 abbiamo scansionato 30.998 app online costruite con Lovable, Base44, Replit, v0 e Bolt. Su 3.680 di queste siamo riusciti a completare il controllo che chiede a un database Supabase, senza login, se una tabella consegnerà le sue righe. In 2.096, il 57%, almeno una tabella lo faceva, e 394 di queste avevano una tabella aperta con un nome di persone: users, profiles, customers, orders.

Ognuno di quei database era crittografato a riposo per tutto il tempo, secondo la descrizione che la piattaforma dà di sé, e qualunque sconosciuto avesse chiesto avrebbe ricevuto le righe via TLS. Nella crittografia non si è rotto niente, e non ha avuto alcun ruolo nel decidere chi riceveva una risposta.

La richiesta in sé è ordinaria. È quella che la tua app fa per mostrare a un cliente con l'accesso i suoi ordini, inviata senza l'accesso: la chiave pubblica che deve stare nella tua pagina, e un GET a /rest/v1/ con il nome di una tabella in fondo. La nostra scansione ha letto quante righe avrebbe restituito ogni tabella e si è fermata lì, senza scaricarne nessuna. La misurazione completa spiega di cosa è una quota quel 57% e quanto non abbiamo potuto vedere.

Supabase è conforme SOC 2?

Sì. Supabase ha un report SOC 2 Type 2 di un revisore indipendente, rinnovato ogni anno.

Un report SOC 2 è il resoconto di un revisore su se i controlli di sicurezza di un'azienda hanno funzionato come l'azienda dice. Type 2 significa che sono stati testati su un intero periodo, e quello di Supabase va dal 1° marzo al 28 febbraio. Copre sicurezza, disponibilità, integrità dell'elaborazione, riservatezza e privacy, sul database, Storage, Auth, Realtime, le Edge Functions e la Data API, e la pagina SOC 2 di Supabase segna dove finisce:

La conformità SOC 2 di Supabase non si estende ad ambienti al di fuori del prodotto Supabase o del controllo di Supabase.

Nella banca, è il rapporto dell'ispettore sul caveau e sui furgoni. Le regole delle tue tabelle ne restano fuori, perché le scrivi tu: il modello di responsabilità condivisa di Supabase mette la gestione degli accessi e l'applicazione dei controlli di sicurezza tra le cose di cui il cliente è sempre responsabile.

Ne seguono altre due cose. Se un cliente ha bisogno che la tua azienda sia conforme SOC 2, la pagina SOC 2 di Supabase dice che un cliente in quella situazione deve mettere in atto i controlli e passare un proprio audit. E se Supabase sia una piattaforma solida su cui costruire è una domanda a parte, con un suo articolo.

Come ottengo il report SOC 2 di Supabase?

Dalla dashboard della tua organizzazione, dal piano Team in su. Si trova in Legal Documents, accanto al certificato ISO 27001 e al questionario di sicurezza standard di Supabase, e un'organizzazione su Free o Pro lì trova invece un pulsante di upgrade.

Team parte da $599 al mese, mentre Pro parte da $25, quindi conviene sapere cosa compra la differenza. La documentazione di Supabase dice che ogni progetto è governato dallo stesso insieme di controlli di conformità, quindi un progetto su Pro gira sulla stessa piattaforma sottoposta ad audit. Team aggiunge i documenti, insieme al single sign-on per la dashboard, backup giornalieri conservati 14 giorni dove Pro li tiene 7, e l'accesso a HIPAA. Se un cliente chiede il report in sé, chiedigli se basta la pagina pubblica sulla sicurezza di Supabase prima di cambiare piano per un PDF.

Supabase è certificato ISO 27001?

Sì, secondo ISO/IEC 27001:2022, come Supabase ha annunciato il 22 aprile 2026.

ISO 27001 certifica un sistema di gestione: le politiche, le valutazioni del rischio e i processi con cui un'azienda protegge le informazioni che detiene. Un ente di certificazione accreditato rilascia il certificato per tre anni e torna ogni anno nel frattempo per verificare che il sistema funzioni ancora. Nella banca, è l'ispettore che esamina come vengono decise e tenute aggiornate le procedure di sicurezza. L'annuncio di Supabase descrive SOC 2 come ampiamente riconosciuto in Nord America e ISO 27001 come ampiamente riconosciuto in Europa, Asia e nel settore pubblico. Il certificato si trova nella stessa sezione Legal Documents, sugli stessi piani.

Supabase è conforme HIPAA?

Può esserlo per il tuo progetto, dopo che hai firmato un Business Associate Agreement con Supabase e pagato il suo add-on HIPAA. Non è automatico, e la pagina SOC 2 di Supabase dice che SOC 2 non lo sostituisce.

Un Business Associate Agreement, o BAA, è il contratto scritto che la legge sanitaria statunitense richiede prima che un'azienda possa trattare informazioni sanitarie protette per conto tuo. Supabase ne firma uno dal piano Team in su. L'add-on non ha un prezzo pubblicato: invii una richiesta, Supabase risponde con il prezzo e la procedura, e un'organizzazione su Free o Pro che fa domanda deve comunque passare a Team una volta approvata.

La firma è l'inizio della tua parte. Il modello di responsabilità condivisa di Supabase elenca cosa deve fare un cliente HIPAA, e questi sono i punti che il proprietario di un'app ha meno probabilità di conoscere già:

• Segnare il progetto come progetto HIPAA, e agire su quello che il Security Advisor segnala al riguardo.
• Attivare l'accesso a due fattori per ogni account nell'organizzazione Supabase.
• Attivare il ripristino point-in-time, che richiede almeno l'add-on di calcolo Small.
• Attivare l'obbligo di SSL e le restrizioni di rete.
• Tenere i dati sanitari fuori dai bucket di storage pubblici.

Anche la crittografia a riposo e in transito è in quella lista, ed è l'unico punto che Supabase ha già fatto.

Supabase è conforme al GDPR?

Supabase supporta app conformi al GDPR e fornisce i due pezzi che solo lui può fornire. Se la tua app è conforme dipende da cosa fa con i dati delle persone.

Il primo pezzo è il luogo. Scegli una regione quando crei un progetto, e una regione UE specifica tiene lì il tuo database, Auth e Storage. Scegli la regione per nome, perché l'opzione generica Europa di Supabase include anche Londra e Zurigo. Il secondo è il Data Processing Addendum, il contratto sul trattamento dei dati che il GDPR richiede tra te e un'azienda che tratta dati personali per tuo conto. Quello di Supabase fa parte dei suoi termini di servizio, quindi ogni organizzazione ne ha già uno.

Il resto spetta alla tua app: perché raccogli ogni campo, come le persone danno il consenso, chi può leggerlo e come lo cancelli quando te lo chiedono. La pagina sul GDPR di Supabase dice apertamente che scegliere una regione non rende da solo un'applicazione conforme. Cosa deve la tua app secondo la legge è una domanda per un avvocato.

Come rispondo al questionario di sicurezza di un cliente?

Dividilo in due mucchi prima di scrivere qualsiasi cosa. Alcune righe chiedono della piattaforma di Supabase e si compilano dai documenti di Supabase. Le altre chiedono del tuo progetto, e sei l'unica persona che può rispondere.

Le righe di Supabase si copiano direttamente dai suoi documenti. Le ultime tre sono quelle per cui il cliente ha mandato il questionario, e per rispondere ti serve il tuo progetto aperto davanti.

Cosa dico a un cliente che chiede chi può leggere i dati?

Lo stato delle tue policy, tabella per tabella, e la data dell'ultimo controllo. "I dati sono crittografati" risponde a una domanda sui dischi rubati, e un cliente che chiede dell'accesso sta chiedendo dello sportello.

Una risposta onesta nomina le tabelle che contengono dati personali e dice che su ognuna la Row Level Security è attiva, con una policy che lega ogni riga alla persona con l'accesso a cui appartiene. Dice quando hai controllato l'ultima volta dall'esterno, come visitatore senza login, che quelle tabelle non restituivano niente. Se una tabella è pubblica di proposito, un elenco di prodotti o articoli pubblicati, lo dice. Poi la parte di amministrazione: chi può aprire la tua dashboard Supabase, con l'autenticazione a due fattori, e dove sta la chiave segreta. Quella chiave si chiama service_role nei progetti più vecchi e sb_secret_… in quelli più nuovi, e il suo posto è su un server.

Per sapere lo stato delle tue tabelle, comincia dal Security Advisor nella tua dashboard Supabase, che elenca ogni tabella con la Row Level Security spenta. Una tabella può superare questo controllo ed essere comunque aperta, tramite una policy che fa entrare tutti. I quattro stati in cui può trovarsi una tabella mostrano come distinguerli, e c'è una guida in linguaggio semplice per le app Supabase.

Metti per iscritto solo quello che hai controllato. Se non hai ancora letto la policy di una tabella, indica la data entro cui lo farai.

Come Reeve controlla la risposta dall'esterno

Le righe che un questionario lascia a te riguardano chi riceve una risposta. Reeve interroga la tua app online come farebbe uno sconosciuto e ti dice quali tabelle hanno risposto.

• La scansione gratuita chiede a ogni tabella nominata dalla tua app quante righe riceverebbe un visitatore senza login, legge il numero e si ferma senza scaricare una riga. Circa 20 secondi, senza account: scansiona la tua app.
• Reeve Monitor ripete tutti e nove i controlli ogni ora su un massimo di tre app e ti scrive il giorno in cui il tuo voto peggiora, quindi una tabella che il tuo builder aggiunge dopo che hai rimandato il questionario viene controllata entro l'ora.
• Care esegue gli stessi controlli e tiene una copia del tuo database Supabase fuori dal tuo account Supabase, presa secondo una programmazione e riletta prima di contare, e questo risponde alla riga sui backup. Ogni copia è crittografata con AES-256-GCM con una chiave che appartiene solo al tuo account, e la nostra pagina legale spiega come vengono custodite queste chiavi. Come una copia viene presa e rimessa al suo posto.

Cosa copre e quanto costa ogni piano è sulla pagina dei prezzi.

Cosa fare adesso

La metà del questionario che riguarda la crittografia ha già la risposta. Prima di rimandarlo, scansiona la tua app e guarda quali delle tue tabelle rispondono oggi a uno sconosciuto.