Lovable: uno studio rileva dati personali accessibili senza autenticazione su migliaia di applicazioni
La società di sicurezza tedesca Crissy Field ha analizzato 159.041 progetti creati con Lovable. Tra i 24.664 siti che restituivano dati da Supabase fin dal caricamento, 7.403 consentivano la lettura di tabelle contenenti indirizzi e-mail e, in alcuni casi, numeri di passaporto o dati di pagamento.
La promessa del «vibe coding» si scontra con una questione molto concreta: chi protegge i dati? La società di sicurezza tedesca Crissy Field ha esaminato 159.041 progetti creati con Lovable, la piattaforma svedese che trasforma una descrizione in linguaggio naturale in un’applicazione web. Il risultato: su migliaia di siti, informazioni personali, talvolta molto sensibili, erano leggibili senza alcuna autenticazione. L’indagine, condotta insieme al quotidiano economico tedesco Handelsblatt (articolo del 2 novembre 2026), è dettagliata in un rapporto pubblicato da Crissy Field con dati aggiornati.
Cosa ha misurato lo studio
Crissy Field si è concentrata su Supabase, il servizio di database che stima essere il più utilizzato dai progetti Lovable. I database proprietari di Lovable, lanciati a fine 2025, non sono stati esaminati.
| Fase | Numero |
|---|---|
| Progetti Lovable identificati in Common Crawl (da dic. 2025 a sett. 2026) | 159.041 |
| Progetti che utilizzano Supabase | 34.545 |
| Siti che inviano record Supabase fin dal caricamento, senza autenticazione | 24.664 |
| Siti in cui le tabelle contenenti indirizzi e-mail erano leggibili | 7.403 (30%), su 10.560 tabelle |
Il primo dato non costituisce di per sé una vulnerabilità: un’applicazione può mostrare pubblicamente determinati dati. Il problema emerge nella fase successiva. Tramite semplici query in sola lettura, utilizzando la stessa chiave API adoperata dal sito, i ricercatori hanno potuto consultare altre tabelle. Crissy Field non pubblica il proprio metodo di accesso per non agevolare ulteriori intrusioni e ha scaricato soltanto estratti dei database.
Dai passaporti ai messaggi privati
Gli esempi citati nel rapporto sono rilevanti:
- un forum tedesco esponeva oltre 80.000 profili (nome, e-mail, data di nascita) e più di 200.000 messaggi di discussione;
- organizzatori di eventi e ristoranti lasciavano accessibili decine di migliaia di record di vendita, contenenti numeri di telefono, indirizzi postali, informazioni di pagamento e codici dei biglietti;
- un amministratore immobiliare esponeva riepiloghi, generati dall’IA, di e-mail interne riguardanti inquilini e partner;
- un fornitore di servizi esponeva oltre 1.000 record con numeri di passaporto, date di scadenza e nazionalità;
- altrove: contratti, fatture, album fotografici, conversazioni WhatsApp interne e 280.000 e-mail inviate ai clienti di un fornitore.
Crissy Field afferma di non sapere se questi dati siano stati sfruttati, ma ricorda che possono essere impiegati per phishing, truffe sui biglietti o furti d’identità.
I limiti della percentuale del 30%
Il rapporto adotta cautela riguardo alla propria statistica. Un indirizzo e-mail può essere un contatto pubblico o un dato di test; al contrario, le schede anagrafiche prive di e-mail sfuggono al conteggio. Il 30% riguarda unicamente i 24.664 siti analizzati da vicino, e il campione estratto da Common Crawl non è rappresentativo della totalità delle applicazioni Lovable. Non si tratta quindi di una percentuale di violazione confermata.
Di chi è la responsabilità?
Crissy Field evidenzia una discrepanza: Lovable sottolinea come non sia richiesta alcuna competenza tecnica, mentre i suoi termini di servizio lasciano ai clienti la responsabilità delle loro applicazioni e dei loro dati. Secondo India Today, che cita Handelsblatt, Lovable ha risposto che il problema non è specifico della sua piattaforma ma coinvolge l’intero settore. Al momento non abbiamo trovato alcuna dichiarazione pubblica dell’azienda.
I ricercatori riconoscono che gli errori nei permessi di accesso si verificano anche nelle applicazioni scritte a mano. Tuttavia, con Lovable, le integrazioni con i database seguono schemi ricorrenti: un approccio efficace contro un’applicazione può essere replicato contro molte altre. Inoltre, gli utenti privi di competenze tecniche incontrano maggiori difficoltà nell’individuare questi errori. Il loro consiglio: verificare i permessi di accesso, le interfacce e la separazione tra gli account prima di gestire dati reali dei clienti, e ripetere il controllo dopo ogni modifica importante.
La nostra lettura
Il problema non è esclusivo dell’IA: un database mal configurato resta tale, sia che sia stato collegato da un essere umano o da un agente. Tuttavia, gli strumenti di generazione di applicazioni moltiplicano il numero di progetti messi online da persone che non sanno che un database privo di regole di accesso ben definite può essere letto ben oltre ciò che l’applicazione mostra. Lo studio non dimostra né una fuga massiva di dati né uno sfruttamento malevolo, e il suo campione non è rappresentativo; evidenzia invece che «senza codice» non significa «senza sicurezza». Per queste piattaforme, la sfida consiste ora nel garantire una configurazione sicura per impostazione predefinita e nel bloccare la pubblicazione online quando dati sensibili rimangono esposti, anziché scaricare la responsabilità sui clienti. Se avete pubblicato un’applicazione di questo tipo, testatela da disconnessi e fate controllare le sue regole di accesso prima di memorizzarvi dati reali.
Fonti
- Crissy Field — Lovable: Many Apps Built on the Platform Expose Sensitive Data (rapporto di ricerca) Fonte primaria
- India Today — AI app-maker Lovable apps expose personal details, researchers find thousands of cases (3 novembre 2026) Fonte secondaria
Una fonte primaria proviene direttamente dall'azienda, dal laboratorio o dall'ente interessato. Una fonte secondaria riporta l'informazione senza esserne l'autrice: la segnaliamo come tale. Un errore? Consulta la nostra politica di rettifica.
