Lovable è sicuro? Cosa abbiamo trovato in 18.554 app Lovable

Hai costruito qualcosa su Lovable, funziona, e stai per metterci persone vere. Da qualche parte in quella settimana hai digitato "lovable è sicuro" in un campo di ricerca, e quello che è tornato era o una pagina su una divulgazione di sicurezza del 2025 o un fornitore che ti vendeva una scansione. Nessuna delle due diceva una parola sull’app che stai per pubblicare.

Ecco cosa sbaglia la maggior parte di quelle risposte: "Lovable è sicuro" sono tre domande vestite da una frase sola, e quella che decide se degli sconosciuti possono leggere i dati dei tuoi utenti è quella che quasi nessuno misura.

Noi possiamo misurarla. Tra il 12 e il 14 agosto 2026 abbiamo passato 30.998 app online per gli stessi nove controlli esterni che chiunque può lanciare gratuitamente dalla nostra homepage, e 18.554 di quelle erano pubblicate su Lovable. È la coorte più grande che abbiamo, tre app su cinque fra tutte quelle che abbiamo mai scansionato. Questo è ciò che è tornato per loro, e dove si ferma la nostra vista.

Lovable è sicuro?

Come piattaforma sì, e con un margine più ampio di quanto ci aspettassimo. Ciò che Lovable produce è risultato il più pulito dei cinque costruttori misurati. Tutto ciò che ha deciso un voto stava dentro l’app costruita dal suo proprietario.

Pensalo come un negozio con il magazzino dall’altra parte della strada. Lovable costruisce il negozio: le vetrine, il bancone, l’insegna. Il magazzino è di Supabase, e ha la propria serratura sulla propria porta. Cosa il negozio consegna a un passante è una domanda. Cosa il magazzino consegna a chiunque si avvicini e chieda è tutta un’altra cosa, e nessun riordino del negozio la cambia.

1. La piattaforma. Lovable pubblica la tua app come si deve: un certificato valido, un dominio che non scade, niente che filtri dalla build. Questo è il negozio.
2. L’agente. Il codice che scrive l’IA di Lovable tiene. Nessuna scansione esterna vede il cablaggio, e questo articolo lo dice invece di tirare a indovinare.
3. L’app che hai pubblicato. Cosa raggiunge uno sconosciuto dal marciapiede: una chiave nel codice che un browser scarica, un bucket di storage che elenca i suoi file, una tabella di database che risponde a chiunque chieda.

I nostri controlli leggono la terza e due parti della prima. Sulla piattaforma, il certificato era valido su tutte le 18.486 app dove ne abbiamo potuto leggere uno, e nemmeno un dominio su 18.554 era vicino alla scadenza. Sull’agente non abbiamo nulla da misurare. Sull’app abbiamo 18.554 risposte.

Cosa abbiamo trovato in 18.554 app Lovable

Nove controlli, dall’esterno, senza accesso e senza entrare nell’account di nessuno. Non abbiamo mai letto una riga: dove un database rispondeva, abbiamo chiesto quante righe avrebbe consegnato e ci siamo fermati lì. Nessuna app viene nominata qui né altrove in ciò che pubblichiamo. Ogni quota qui sotto è sulle app su cui il controllo ha risposto, perché un controllo che non è riuscito a finire è sconosciuto e non superato, ed è quella regola a far muovere i denominatori. Metodo e dati sono nel rapporto.

I voti: 15.963 A, 370 B, 1.814 C, 402 D e 5 F. Nove app non avevano alcun rilievo.

Quella prima riga è il motivo per cui "il 99 % delle app Lovable ha un problema di sicurezza" è una frase che leggerai da qualche parte e dovresti ignorare. Gli header di sicurezza del browser li manda ciò che serve la tua pagina, e su tuaapp.lovable.app è Lovable, ed è per questo che ogni app su quell’host riceve la stessa risposta. Vale la pena averli e non sono ciò di cui è fatta una D.

Togli quella riga e 15.453 delle 18.554 app non avevano nient’altro. Le 3.092 rimanenti sono il resto di questo articolo.

Cosa Lovable fa bene, ed è quasi tutta la lista

Tre dei numeri qui sopra sono i migliori che abbiamo registrato su qualunque costruttore, e tutti e tre li decide la piattaforma e non tu.

Le source map. 225 app Lovable su 18.553 pubblicano i file originali dietro l’app, commenti compresi. Fa circa 1 su 80. Su Base44 lo stesso controllo scatta sul 59 % delle app, e su Replit sul 6 %. La build di produzione di Lovable fa la cosa giusta per impostazione predefinita, quindi questo di solito non è un tuo problema.

Gli header cross-origin. Zero app su 18.518 hanno detto a un sito qualunque del mondo che poteva chiamare la loro API, e zero lo hanno permesso con i cookie di accesso del visitatore. È il rilievo che più facilmente lascia un altro sito agire come il tuo utente, e su Lovable non è comparso nemmeno una volta.

File privati smarriti. Zero app su 18.442 servivano un .env o un .git/config da un URL normale. Un’app Lovable non ha un server proprio da configurare male, quindi non c’è nessun file dimenticato sul retro.

Niente di tutto questo è un premio di consolazione. È la parte del lavoro a cui non hai dovuto pensare e a cui, sulla maggior parte degli altri costruttori, qualcuno pensa.

L’unico numero che conta: 2.017 su 3.553

Delle app Lovable il cui database Supabase siamo davvero riusciti a interrogare, il 57 % ha consegnato righe a una richiesta che non portava alcun accesso.

Vale la pena percorrere i denominatori, perché questo è il numero che tutti citano e quasi nessuno inquadra. Su 18.554 app Lovable, 6.532 nominavano un progetto Supabase nel codice che consegnano. Di quelle, 3.553 hanno risposto abbastanza bene da permetterci di giudicare, e le altre 2.979 no, quindi sono sconosciute e non pulite. Delle 3.553, 2.017 hanno restituito righe a uno sconosciuto.

In 373 di quelle app la tabella che rispondeva aveva un nome di persone: users, profiles, orders, messages. Sono 373 app, non 373 tabelle. Nelle altre 1.644 era qualcosa che dall’esterno non abbiamo potuto nominare: forse un catalogo prodotti che doveva essere pubblico da sempre, forse tutt’altro.

Misurate su tutte le app Lovable scansionate invece che sul sottoinsieme che abbiamo potuto giudicare, 2.017 su 18.554 fanno circa 11 su 100. Tieni a mente quel numero per due sezioni.

Perché ricade sul database e non su Lovable

Per una scelta di progettazione che è corretta, deliberata, e quasi mai spiegata alla persona che riguarda.

Un’app Lovable non ha un server proprio. La pagina nel browser del visitatore parla direttamente con Supabase, ed è per questo che il tutto si può costruire in un pomeriggio e per questo che così poche di queste app hanno una rotta API aperta: non c’è nessuna API tua da lasciare aperta. Perché funzioni, l’indirizzo del tuo database e una chiave per raggiungerlo devono essere stampati dentro l’app, dove chiunque può leggerli. Quella chiave è la chiave pubblicabile, e il fatto che sia pubblica è corretto. Deve stare lì.

Il che significa che l’unica cosa tra uno sconosciuto e la tua tabella users è un’impostazione Supabase per tabella chiamata Row Level Security. Accesa e con una policy scritta, la chiave pubblica legge solo le righe che quella policy consente. Spenta, la chiave pubblica legge la tabella.

Ora la parte che decide la maggior parte dei progetti Lovable. Supabase accende Row Level Security per impostazione predefinita sulle tabelle che crei cliccando nel Table Editor. Le tabelle create eseguendo SQL non la ricevono, ed eseguire SQL è il modo in cui un costruttore crea tabelle per te. La forma consueta di un progetto Lovable è quindi: qualche tabella fatta a mano, che è protetta, accanto a quelle generate, che potrebbero non esserlo. Le due sembrano identiche. Nessuna si lamenta. L’app funziona perfettamente in entrambi i casi, e questo è tutto il problema: nulla di ciò che vedi da davanti ti dice quale delle due hai.

La versione lunga, con l’SQL, è qui, e la guida in linguaggio semplice per questa piattaforma è la tua app Lovable è sicura.

La policy che cancella l’errore e lascia la tabella aperta

Accendere Row Level Security è il passo uno di due, ed è al passo due che un assistente IA fa molto volentieri la cosa sbagliata.

Con l’impostazione accesa e nessuna policy scritta, la tua stessa app smette di funzionare. Ottieni un errore, lo incolli nella chat, e torna qualcosa che fa sparire l’errore. Molto spesso ciò che torna è una policy che consente a tutti, scritta come using (true). È una policy valida. Soddisfa il requisito che una policy esista. Consente ogni riga a ogni richiesta.

Il pannello ora segnala la tabella come protetta, l’errore è sparito, la tua app funziona, e la tabella è leggibile esattamente come prima. Su questo abbiamo un articolo intero perché è il fallimento più convincente di tutto lo stack: RLS è acceso e la tua tabella è ancora pubblica.

Se hai mai incollato un errore di Row Level Security in una finestra di chat e accettato la prima correzione che ha fatto passare la build, vai a leggere quella policy oggi.

CVE-2025-48757, e perché non è più la tua domanda

È reale, è stata seria, e dal lato di Lovable è chiusa da oltre un anno. Non è nemmeno ciò che dovresti controllare.

A maggio 2025 il ricercatore di sicurezza Matt Palmer ha pubblicato CVE-2025-48757, sulle app Lovable le cui tabelle Supabase avevano Row Level Security assente o scritta in modo troppo permissivo. Ha scansionato 1.645 app Lovable e ne ha trovate 170 con database esposti. La risposta di Lovable è stata aggiungere un controllo di sicurezza che gira prima della pubblicazione e avverte sulle tabelle non protette.

Ed ecco la lettura onesta, ed è il motivo per cui la CVE è l’inquadratura sbagliata. Quella divulgazione trovava circa 10 app esposte ogni 100. Sedici mesi dopo, su una coorte undici volte più grande, ne abbiamo trovate circa 11 ogni 100. I denominatori non sono identici e nessuno dei due campioni è l’internet intero, quindi prendi i due come lo stesso ordine di grandezza e non come un confronto preciso. La direzione è abbastanza chiara: il tasso non è sceso.

Non è una correzione fallita. È il segno che non è mai stata davvero una vulnerabilità di un prodotto. È un’impostazione sulle tue tabelle, nel tuo progetto Supabase, che nessun altro può accendere al posto tuo. Una patch lì non arriva, ed è esattamente per questo che ci arriva un controllo che esegui tu.

Di cosa erano fatte davvero le 822 chiavi

Quasi tutte andavano bene, e uno scanner che ti dicesse il contrario ti starebbe insegnando a ignorarlo.

822 delle 18.554 app Lovable avevano qualcosa a forma di chiave nel codice che un visitatore scarica. Letta come un elenco di forme, fa il 4 % delle app che "perdono segreti". Letta come ciò che ogni chiave può davvero fare, viene così:

Le 727 chiavi Google sono il motivo per cui classifichiamo invece di limitarci a riconoscere forme. Una chiave Google Maps in un browser è dove deve stare, e la correzione è limitarla al tuo dominio invece di farsi prendere dal panico.

Sono le ultime quattro righe a contare, e sono rare: 30 app su 18.554. Sono anche i rilievi che costano denaro da soli, e di solito emergono come una fattura che arriva prima che qualcuno se ne accorga. Due dettagli a verbale. Tutte e tre le chiavi service_role dell’intera scansione su 30.998 app erano in app Lovable, e così due dei tre segreti Stripe di produzione. Una chiave service_role nel browser rende irrilevante in una riga ogni policy di Row Level Security del tuo progetto, ed è per questo che è l’unico rilievo che classifichiamo critico a vista e quello da ruotare in giornata.

Distinguere i due tipi richiede circa un minuto, e abbiamo scritto la guida.

I 768 bucket di storage che nessuno voleva aprire

Un bucket Supabase contrassegnato come pubblico non serve solo i file a cui la tua app rimanda. Elenca anche ogni file che contiene a chiunque lo chieda.

768 delle 16.565 app Lovable controllabili avevano almeno un bucket che elencava il proprio contenuto. Il motivo è lo stesso delle tabelle leggibili: rendere pubblico un bucket è il modo per far comparire un’immagine, funziona subito, e dopo nulla ti dice che l’elenco era compreso. Fatture caricate, foto di documenti e avatar degli utenti finiscono tutti nello stesso posto. Cosa espone davvero un bucket pubblico copre la correzione, che sono URL firmati e non un bucket privato da cui poi non riesci a leggere.

Il controllo di cinque minuti sulla tua app Lovable

Ogni punto è una pagina che apri. Usa una finestra privata, così il tuo accesso non risponde al posto di uno sconosciuto.

1. Supabase → Authentication → Policies. Scorri l’elenco. Qualunque tabella che mostri Row Level Security disattivata è leggibile da chiunque abbia l’indirizzo del tuo progetto, che è stampato nella tua app.
2. Leggi le policy delle tabelle che invece ce l’hanno accesa. Se una consente a tutti, la tabella è aperta e il pannello continua a chiamarla protetta.
3. Supabase → Storage. Qualunque bucket contrassegnato come pubblico elenca i suoi file a chiunque. Guarda cosa c’è dentro prima di decidere che va bene.
4. Supabase → Settings → API. Conferma che la chiave che la tua app consegna sia quella pubblicabile. Se una chiave segreta è mai stata incollata nel progetto, ruotala lì prima di cancellarla dal codice, perché il vecchio valore funziona finché non lo fai.
5. Oppure lascia fare alla scansione. Esegue quei quattro dall’esterno e altri cinque, impiega circa 20 secondi, non chiede un account, e ti mostra un voto e cosa lo ha prodotto: scansiona la tua app.

Se preferisci percorrere l’intera superficie come un elenco, la checklist di sicurezza in 10 minuti copre ciò che vale la pena confermare su qualunque app appena lanciata, e chiunque può leggere il tuo database Supabase è il test da fare se ne fai uno solo.

La tua app cambia a ogni pubblicazione

Una scansione lanciata il mese scorso descrive l’app del mese scorso, e su Lovable è un mese più corto della media.

Pubblicare è un clic, quindi una modifica è online nel momento in cui la accetti. Non c’è nessun passaggio di deploy tra te e internet a intercettare una tabella aggiunta stamattina senza Row Level Security, o una chiave incollata nella chat a mezzanotte per superare una build che falliva. Ognuno dei 2.017 database esposti che abbiamo trovato apparteneva a qualcuno la cui app funzionava benissimo.

Reeve Monitor è la versione di questo articolo che si esegue da sola. Ripete tutti e nove i controlli ogni ora su un massimo di tre app, guarda ogni 60 secondi se l’app risponde, ti avvisa quando un risultato cambia invece di aspettare che tu guardi, e manda un rapporto mensile. Costa €12 al mese a listino, con sette giorni gratuiti prima dell’addebito; la pagina dei prezzi sta a volte sotto la cifra indicata qui e mai sopra.

Se la tua app Lovable usa Supabase, e 6.532 delle 18.554 scansionate lo fanno, l’altra metà del problema è la copia. Una tabella esposta è una cosa che uno sconosciuto può leggere. Un agente con accesso al database, o una migrazione andata al contrario, è una cosa che può cancellarla, e il backup giornaliero di Supabase sul piano gratuito non è qualcosa che tu possa ripristinare da solo. Reeve Care prende ogni notte una copia cifrata del tuo database Supabase, la tiene dove il tuo progetto non arriva, verifica che ogni copia si ripristini davvero, e ti dà un ripristino in un clic quando serve. Tutto ciò che fa Monitor è incluso. Care costa €49 al mese a listino per un’app, con gli stessi sette giorni gratuiti.

La forma di quel secondo fallimento, raccontata da qualcuno a cui è successo, è il giorno in cui un agente IA ha cancellato un database di produzione. Nessuno dei nove controlli di questo articolo avrebbe aiutato lì. Una copia sì.

Cosa fare questa settimana

Lovable ha fatto bene la sua metà. I 2.017 sono la metà che è tua, ed è un’impostazione e non una riscrittura. Se invece vuoi il confronto tra costruttori, quale costruttore di app con IA è il più sicuro ha la tabella per tutti e cinque.