Nessuna vulnerabilità, nessun exploit, nessun malware: bastava aprire l'indirizzo giusto. È questo il dato che rende la ricerca di UpGuard sui database Supabase più istruttiva di tanti zero-day. Secondo i ricercatori, su circa 300.000 domini analizzati sono emersi 16.326 database Supabase con tabelle leggibili pubblicamente, e più della metà mostrava indicatori di dati personali.

Cosa è successo

Supabase è una piattaforma di backend molto usata per costruire applicazioni web e mobile, incluse quelle generate con strumenti di "vibe coding" come Lovable, in cui l'applicazione viene scritta in gran parte da un assistente AI. UpGuard ha censito i progetti raggiungibili senza autenticazione e ha rilevato tra i dati esposti nomi, indirizzi e numeri di telefono, token di autenticazione, messaggi privati, dati di localizzazione e, in un sottoinsieme minore, password e persino documenti di identità. Tra gli esempi citati dalle fonti: un servizio di valet negli Stati Uniti con oltre 100.000 record clienti, un servizio filippino che lasciava leggibili più di 100.000 SMS con relativi codici OTP, un database di un consolato africano con circa 25.000 record e un servizio di immigrazione canadese con quasi 5.000 record, di cui 884 account con password in chiaro. Nei rari casi di e-commerce e ristorazione sono comparsi anche dati di pagamento.

Le fonti concordano sulla causa: configurazione. Le cause indicate sono policy di sicurezza a livello di riga (Row Level Security, RLS) assenti o inefficaci, chiavi pubbliche trattate come se fossero segrete, controlli disponibili ma non attivati. Una delle fonti segnala anche il caso delle tabelle create via API, dove la RLS non è attiva di default. Supabase, per bocca del suo responsabile della sicurezza, sostiene che i progetti siano "sicuri per impostazione predefinita" e che la sicurezza sia una responsabilità condivisa con il cliente. Le due affermazioni non sono necessariamente in contraddizione: la piattaforma offre gli strumenti, ma chi costruisce l'app deve usarli.

Un chiarimento sui numeri: la cifra di 16.326 è quella riportata da Cybernews e ITNerd, mentre TechCrunch parla di "circa 16.000". Il numero di persone coinvolte non è stato quantificato, perché lo stesso utente può comparire in più database.

Perché succede: il meccanismo, spiegato bene

In Supabase il browser o l'app mobile dialogano direttamente con il database tramite API. La chiave "anon" è per progetto ed è pensata per essere pubblica, cioè visibile nel codice del client: ciò che protegge i dati non è la segretezza della chiave, ma le policy RLS che stabiliscono chi può leggere o scrivere quali righe. Se la RLS non è attivata su una tabella, o la policy è scritta in modo troppo permissivo, chiunque conosca l'indirizzo del progetto e la chiave pubblica, entrambi presenti nel codice dell'app, può interrogare la tabella intera.

Un assistente AI che genera un'app "che funziona" tende a ottimizzare per il funzionamento: se una tabella non si legge perché la RLS blocca l'accesso, la scorciatoia più rapida è disattivare la protezione. Chi non ha competenze di sicurezza non lo nota, perché l'app continua a girare. È questo il filo conduttore con altri episodi recenti, come gli agenti AI che pubblicano screenshot aziendali su GitHub: lo strumento fa ciò che gli viene chiesto, non ciò che sarebbe prudente.

Cosa significa per le aziende italiane

Il punto di vista da consulente è questo: il rischio non riguarda i grandi gruppi con un team di sicurezza, ma tre categorie molto italiane.

Le PMI che commissionano un'app o un portale "veloce" a una software house o a un freelance, magari con un prototipo generato con l'AI. Il committente è quasi sempre il titolare del trattamento ai sensi del GDPR: se i dati dei suoi clienti sono leggibili da chiunque, la responsabilità verso il Garante è sua, anche se la configurazione l'ha fatta un fornitore. Il contratto con il fornitore dovrebbe prevederlo come responsabile del trattamento (art. 28), con obblighi di sicurezza verificabili; nella pratica spesso non c'è nulla di scritto.

I reparti interni che costruiscono strumenti in autonomia (shadow IT con l'AI): un modulo per raccogliere candidature, un'app per prenotazioni, un gestionale di magazzino con anagrafica clienti. Nascono senza passare dall'IT, quindi senza valutazione dei rischi né registro dei trattamenti.

I soggetti NIS2 e le filiere regolate. Per un soggetto rientrante in NIS2 le applicazioni sviluppate da terzi fanno parte della sicurezza della catena di approvvigionamento; per le entità finanziarie il tema ricade nella gestione del rischio ICT di terze parti prevista da DORA. Un fornitore che usa questi strumenti senza controlli è un rischio da mappare, non un dettaglio tecnico.

Sul piano GDPR, l'esposizione pubblica di dati personali per configurazione errata è una violazione della sicurezza del trattamento (art. 32) e, quando c'è accesso non autorizzato o anche solo concreta possibilità di accesso a dati personali, va valutata come data breach. L'eventuale notifica al Garante deve avvenire entro 72 ore dalla scoperta, salvo che sia improbabile un rischio per i diritti e le libertà delle persone; se il rischio è elevato (password, documenti di identità, messaggi privati) scatta anche la comunicazione agli interessati. Un fattore aggravante: dati come documenti e OTP aprono la strada a frodi di identità e a furti di account, quindi la valutazione del rischio raramente può concludersi con "improbabile".

Va detto che le fonti non indicano esplicitamente quanti database appartengano a soggetti europei o italiani, per cui non si può dire quante aziende italiane siano coinvolte. La conclusione solida è un'altra: il pattern è ripetibile ovunque, e chiunque abbia un'app su Supabase (o su un servizio analogo) dovrebbe verificarlo.

Cosa fare subito

  • Censire le applicazioni che usano Supabase o altri backend-as-a-service (Firebase, Appwrite e simili), compresi prototipi, strumenti interni e app dei fornitori; chiedere ai fornitori un elenco scritto.
  • Verificare che la RLS sia attiva su ogni tabella dello schema esposto e che le policy non siano del tipo "consenti tutto"; nel pannello Supabase è disponibile un controllo di sicurezza (advisor) che segnala le tabelle senza protezione.
  • Testare dall'esterno: provare le API con la sola chiave pubblica, come utente anonimo e come utente autenticato di basso livello, e controllare che non restituiscano righe di altri utenti.
  • Controllare che nel codice client non compaiano chiavi riservate: la chiave "service role" non deve mai trovarsi in un'app web o mobile; se c'è stata, va ruotata subito.
  • Ruotare le credenziali e invalidare le sessioni se si trova un'esposizione, conservando i log di accesso per ricostruire cosa è stato letto.
  • Attivare la procedura di data breach con il DPO: valutazione del rischio documentata, decisione motivata sulla notifica al Garante entro 72 ore, comunicazione agli interessati se il rischio è elevato.
  • Inserire un passaggio di revisione di sicurezza prima della messa online di qualsiasi app generata con l'AI, e clausole contrattuali con i fornitori su configurazione sicura, test e responsabilità.
  • Non conservare password in chiaro: se un'app lo fa, è un difetto di progettazione da correggere indipendentemente dall'esposizione.

Il punto

Il caso Supabase non dimostra che l'AI scriva codice inevitabilmente insicuro, né che la piattaforma sia difettosa. Dimostra che abbassare la barriera per costruire software senza abbassare quella per metterlo in sicurezza produce incidenti in serie. Per le aziende la domanda utile non è "usiamo Supabase?", ma "chi ha controllato la configurazione prima che i dati dei nostri clienti ci finissero dentro?".