--- title: "Supabase è sicuro? Cosa copre e cosa spetta a Lei" description: "Supabase è certificato SOC 2 Type 2 e ISO 27001 e cifra i dati. Che i suoi dati siano al sicuro dipende da impostazioni che controlla solo Lei." url: "https://madsalt.tech/it/blog/is-supabase-secure/" author: "Denys Zaichenko" language: "it" published: 2026-10-26 --- # Supabase è sicuro? Cosa copre e cosa spetta a Lei 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](https://supabase.com/security) e dalla [documentazione sulla sicurezza](https://supabase.com/docs/guides/security) 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](https://supabase.com/docs/guides/security/soc-2-compliance) 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](https://supabase.com/docs/guides/deployment/shared-responsibility-model) 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 presidia ogni passaggio di una richiesta. Supabase gestisce trasporto e chiavi; grant e policy sono suoi. Da un browser: Browser → TLS, chiave · Supabase → Grant · lei → RLS · lei; Dal suo server: Server → TLS · Supabase → Secret key · lei → RLS saltata.](https://madsalt.tech/charts/it/is-supabase-secure.svg) *Figura 1. Dal modello di responsabilità condivisa di Supabase e dalla sua guida alle API keys, ottobre 2026.* 1. **Chi può toccare una tabella.** I grant decidono se `anon` e `authenticated` raggiungono una tabella. Le policy RLS decidono quali righe. 2. **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](https://madsalt.tech/it/blog/supabase-anon-key-vs-service-role-key/). 3. **Impostazioni di autenticazione.** Conferma via email, leaked password protection (piano Pro e superiori), lunghezza minima della password, MFA, URL di reindirizzamento, CAPTCHA. 4. **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](https://mattpalmer.io/posts/2025/05/statement-on-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](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) 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](https://madsalt.tech/it/blog/supabase-october-30-grant-change/). ## 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](https://madsalt.tech/it/tools/supabase-security-check/) 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](https://madsalt.tech/it/blog/lovable-app-security-checklist/). - 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](https://madsalt.tech/it/blog/how-to-test-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](https://madsalt.tech/it/#contact)