In breve
Sì, la piattaforma è sicura: Supabase è certificato SOC 2 Type 2 e ISO 27001, cifra i dati a riposo con AES-256 e in transito con TLS e firma accordi HIPAA dal piano Team in su. Il suo progetto è un’altra questione. Secondo il modello di responsabilità condivisa di Supabase, l’accesso alle tabelle, le API keys e le impostazioni di autenticazione sono suoi, e la piattaforma fa esattamente ciò che quelle impostazioni dicono. Sulla mia tabella di test locale, una sola impostazione decideva se una chiave pubblica otteneva 0 righe o tutte e 3.
Sono Denys, ingegnere full-stack e di IA, e la maggior parte delle app che costruisco o riparo gira su Supabase. I clienti chiedono “Supabase è sicuro?” intendendo “i miei dati sono al sicuro?”. Sono due domande con risposte diverse, quindi le prendo una alla volta.
Supabase è sicuro?
La parte di piattaforma è sottoposta ad audit di terzi. Dalla pagina sulla sicurezza e dalla documentazione sulla sicurezza di Supabase, lette il 23 ottobre 2026:
| Controllo | Cosa dichiara Supabase |
|---|---|
| SOC 2 Type 2 | Audit annuale; il report è disponibile per i clienti Team ed Enterprise |
| ISO 27001 | Certificato; il certificato è disponibile per i clienti Team ed Enterprise |
| HIPAA | Supportato con un Business Associate Agreement firmato e l’add-on HIPAA, dal piano Team in su |
| Cifratura | AES-256 a riposo, TLS in transito; i token di accesso e le chiavi sono cifrati anche a livello di applicazione |
| Backup | Giornalieri per i progetti a pagamento; Point in Time Recovery come add-on dal piano Pro |
| Residenza dei dati | Database, Auth e Storage restano nella regione AWS che sceglie |
Nulla di tutto questo protegge una tabella che ha lasciato aperta. La guida SOC 2 lo dice chiaramente: la conformità di Supabase non si trasferisce a ciò che sfugge al suo controllo.
Qual è la sua parte?
Il modello di responsabilità condivisa di Supabase elenca ciò che è sempre suo: il suo account, la gestione degli accessi al database e alle sue tabelle, i suoi dati e l’applicazione dei controlli di sicurezza, compresi gli avvisi sollevati dal Security Advisor. In pratica sono quattro livelli di impostazioni:
- Chi può toccare una tabella. I grant decidono se
anoneauthenticatedraggiungono una tabella. Le policy RLS decidono quali righe. - Quale chiave va dove. La publishable key è pubblica per costruzione, la secret key aggira la RLS. Le ho confrontate in Supabase anon key vs service role key.
- Impostazioni di autenticazione. Conferma via email, leaked password protection (piano Pro e superiori), lunghezza minima della password, MFA, URL di reindirizzamento, CAPTCHA.
- Tutto ciò che circonda il database. Bucket di storage e relative policy, funzioni
SECURITY DEFINER, Edge Function che usano la secret key e quali schemi espone la Data API.
Quanto cambia una sola impostazione?
Ho eseguito la stessa richiesta su una tabella di tre ordini finti su uno stack Supabase locale (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), con la publishable key, come farebbe un browser:
| Impostazione sulla tabella | Cosa ha ottenuto la chiave pubblica |
|---|---|
| RLS disattivata | Tutte e 3 le righe, e un insert ha restituito 201 Created |
| RLS attiva, nessuna policy | [] |
RLS attiva, policy using (true) |
Tutte e 3 le righe |
Nessun grant per anon |
42501 permission denied |
Stessa piattaforma, stessa cifratura, stesse certificazioni. La differenza è una riga di SQL. Per questo una “piattaforma sicura” e un’app che perde dati non sono in contraddizione: la CVE-2025-48757 ha trovato 170 delle 1.645 app vetrina di Lovable che servivano dati alla chiave pubblica, tutte sulla stessa piattaforma sottoposta ad audit.
Supabase sta diventando più sicuro di default?
Sì, a piccoli passi. Il changelog del 28 aprile 2026 di Supabase elenca un’opzione per la RLS attiva di default, un badge di esposizione della Data API, grant granulari per tabella e una restrizione sull’enumerazione degli schemi. Il più grande arriva il 30 ottobre 2026: le nuove tabelle dei progetti esistenti smettono di ricevere automaticamente i grant per la Data API, così una tabella dimenticata restituisce 42501 invece delle sue righe. Le tabelle esistenti mantengono i loro grant, quindi questo non risolve nulla di ciò che è già aperto. Anche le vecchie chiavi anon e service_role vengono deprecate entro la fine del 2026 a favore di publishable e secret keys; la nuova secret key rifiuta le richieste da un browser.
Cos’altro rompe il passaggio e come controllare il progetto prima: Supabase, cambio dei grant del 30 ottobre: cosa controllare.
Come si controlla il proprio progetto?
Parta dal Security Advisor di Supabase e corregga ogni avviso. Poi controlli ciò che non copre:
- Esegua il Controllo sicurezza Supabase gratuito. Si collega in sola lettura e valuta il progetto su 46 regole associate alla OWASP Top 10:2025: RLS, policy, viste, funzioni, grant, storage e impostazioni di autenticazione, con l’SQL di correzione per ogni rilievo.
- Testi con due utenti in due aziende. Nessuno scanner sa a chi appartengono le righe; il test è nella mia checklist di sicurezza per le app Lovable.
- Se la sua app ha ruoli e una schermata dei permessi, dimostri che ogni casella di permesso fa ciò che dice, come in come testare la Supabase RLS.
Quindi: Supabase è un posto sicuro dove tenere i dati e Le dà gli strumenti per mantenerli privati. Se restano privati lo decidono il suo schema e le sue impostazioni.
Sta valutando Supabase per un progetto?
Mi confronto volentieri su cosa configurare per primo. Nessuna vendita.
Mi contatti