Scansione di sicurezza Lovable: cosa non può dimostrare

Premi Publish sulla tua app Lovable e prima che esca parte una scansione. Pochi secondi dopo torna pulita, oppure torna con un elenco, e in tutti e due i casi hai in mano un risultato che non sai giudicare. È tutto qui? Basta per metterci persone vere?

Ed ecco la parte che conviene sapere prima di decidere: la scansione di sicurezza di Lovable e una scansione della tua app pubblicata leggono due oggetti diversi. Una legge le serrature e i cablaggi. L’altra si avvicina e abbassa la maniglia. Valgono entrambe, e solo la seconda fa quello che fa ogni visitatore della tua app tutto il giorno.

Lovable controlla la mia app per problemi di sicurezza?

Sì, e sono due. Sono tutte e due gratuite.

La Quick scan parte da sola a ogni pubblicazione e finisce in pochi secondi. La Deep scan legge tutto il codice della tua app e la avvii tu. Tutte e due leggono il tuo progetto dall’interno: le impostazioni del database, le regole di accesso sulle tue tabelle, l’albero delle dipendenze, il codice.

Tutto quello che segue è stato letto sulla documentazione di sicurezza di Lovable il 24 settembre 2026. Questa funzione è cambiata più di una volta in un anno, quindi guarda la data di qualsiasi articolo che la descriva, questo compreso.

Cosa controlla la scansione di sicurezza di Lovable

Tre aree, come serie fissa di controlli, in pochi secondi, a ogni pubblicazione.

La documentazione di Lovable le chiama revisione del database, audit delle dipendenze e controllo del server MCP. La revisione del database è quella che conta in questo articolo, e la sua descrizione merita una lettura lenta: copre le tabelle senza controllo di accesso per record, cioè senza Row Level Security, oltre alle regole di accesso che fanno passare tutti e alla protezione contro le password trapelate disattivata. L’audit delle dipendenze cerca vulnerabilità note nei tuoi pacchetti npm. Il controllo MCP cerca un server MCP che la tua app espone senza autenticazione.

I risultati tornano raggruppati per area ed etichettati Critical, Warning o Info. La scansione scatta in automatico dalla finestra di pubblicazione, e puoi anche avviarla dalla vista Security del progetto.

Alcuni articoli la chiamano Basic scan. Il comando nella vista Security oggi dice Run quick scan, quindi se un articolo e il tuo schermo non vanno d’accordo sul nome, quello aggiornato è il tuo schermo.

Cosa aggiunge la Deep scan

Legge tutto il codice della tua app, e non parte da sola.

La Deep scan comprende tutto quello della Quick scan e poi guarda la tua logica, i tuoi permessi e i tuoi dati. Lovable elenca sette aree: controllo degli accessi e autorizzazione, endpoint non autenticati e sfruttabili, input non sicuro e injection, segreti e credenziali trapelati, pagamenti e fatturazione, autenticazione e sicurezza degli account, e dati personali e sensibili esposti. È gratuita anche lei.

La frase della documentazione su cui agire davvero è questa: la Deep scan non parte in automatico mentre lavori. Parte quando la fai partire tu. Un progetto in cui non ne è mai partita una non ha mai avuto il codice letto, per quante volte sia stato pubblicato, e la finestra di pubblicazione non te lo dice. Gli spazi di lavoro Enterprise possono programmare Deep scan su progetti scelti dal Workspace Security center, ed è l’unica configurazione in cui succede senza che qualcuno se ne ricordi.

Lovable può anche tentare delle correzioni, mentre costruisci o con Try to fix all nella vista Security. Leggi cosa ha cambiato una correzione prima di accettarla. La riparazione che fa sparire un errore di row level security è molto spesso una policy che fa passare tutti, e quella policy soddisfa il controllo e lascia la tabella aperta.

La critica del 2025, e cosa è cambiato

La prima versione di questo controllo ti diceva che una policy esisteva. Non ti diceva se la policy funzionava, e il ricercatore che ha trovato il problema originale lo ha scritto lui stesso all’epoca.

A maggio 2025 Matt Palmer ha pubblicato CVE-2025-48757, sulle app Lovable le cui tabelle Supabase avevano il row level security assente o scritto in modo troppo largo. La risposta di Lovable è stata il controllo prima della pubblicazione. Il testo di Palmer descriveva il suo limite in una parentesi:

La funzione Publish di Lovable aiuta a garantire che le policy RLS siano attive su tutte le tabelle e segnala quando non lo sono (ma non indica necessariamente se sono sufficienti).

Quel vuoto ha una risposta nella documentazione attuale, che nomina le regole di accesso che fanno passare tutti fra le cose che la revisione del database segnala. Niente in questo articolo mette alla prova quell’affermazione. Se la vuoi verificare, crea una tabella usa e getta con una policy che fa passare tutti e guarda se la scansione la nomina. La versione lunga del CVE sta in Lovable è sicuro.

Cosa una scansione dall’interno non può dimostrare

Se la tua app online consegna righe a qualcuno che non ha fatto il login.

Una serratura può essere montata, registrata e corretta sul disegno, e la porta aprirsi lo stesso. Una policy è una dichiarazione su cosa dovrebbe succedere; quello che decide cosa succede è una richiesta. Tre modi in cui una regola risulta presente e la tabella risponde comunque:

• La policy fa passare tutti. Scritta come using (true), è una policy valida, soddisfa il requisito che ne esista una, e restituisce ogni riga a ogni chiamante.
• La policy copre la lettura e nient’altro. Il select viene controllato, insert, update e delete non sono mai stati scritti, quindi chiunque può scrivere in una tabella che nessuno può leggere per intero.
• La condizione corrisponde a più persone di quante doveva. Doveva nominare un cliente solo e nomina ogni visitatore con la sessione aperta, o ogni visitatore.

Ora la parte che decide come leggere un risultato verde. Da fuori, quei tre casi e una tabella senza nessuna protezione danno la stessa risposta, cioè righe. I tuoi utenti non li distinguono. Nemmeno chiunque altro apra la tua app.

Fra il 12 e il 14 agosto 2026 abbiamo passato gli stessi nove controlli esterni su 30.998 app online, e 18.554 di quelle erano pubblicate su Lovable. Fra le app Lovable che nominavano un progetto Supabase, 3.553 ci hanno risposto in modo abbastanza chiaro da poter essere giudicate, e 2.017 di quelle hanno restituito righe a una richiesta che non portava nessun login. Il metodo e ogni denominatore stanno nel rapporto.

Una nota di onestà su quel numero. Noi stavamo sul marciapiede, e non abbiamo nessuna vista dentro quei progetti. Possiamo riferire cosa hanno risposto 2.017 app pubblicate. Non possiamo riferire quante di quelle avevano fatto partire una scansione, né cosa gli avesse detto.

La tua app risponde alla stessa domanda in una ventina di secondi, e non devi crederci sulla parola su quale lato delle 2.017 si trovi: scansiona la tua app. La scansione chiede a ogni tabella il numero di righe che riceverebbe un chiamante senza login, legge il numero e si ferma lì, senza tirare fuori una sola riga.

Cosa una scansione da fuori non può vedere

Abbassare la maniglia non ti dice niente su una stanza senza porta sulla strada, e di quelle ce ne sono quattro.

Il tuo albero delle dipendenze npm non sta nella pagina che scarica un browser. Il tuo codice lato server, comprese le edge function e la questione se una route controlli chi sta chiamando, gira in un posto che non raggiungiamo mai. Una tabella che il tuo front-end non nomina mai per noi è invisibile, perché troviamo i nomi delle tabelle nel codice che la tua app consegna più un breve elenco di nomi comuni: una tabella che nel browser non compare e che nessuno indovinerebbe non viene interrogata. E un server MCP non è qualcosa che una richiesta di pagina trovi.

Le due scansioni di Lovable fra loro leggono tutte e quattro. La nostra scrive "Non è stato possibile controllare" quando non ha potuto rispondere a una domanda, invece di una spunta.

La riga su cosa consegna la tua app pubblicata a uno sconosciuto è il motivo per farle tutte e due, ed è la riga attorno a cui la nostra scansione è costruita. La versione generale di dove si ferma la vista da fuori sta in cosa si perde una scansione da URL.

Tutte e due, e in quest’ordine

La scansione dall’interno prima di pubblicare, quella da fuori dopo, perché questo è l’ordine in cui le due cose accadono.

1. Lascia partire la Quick scan alla pubblicazione, e poi leggila. Sono pochi secondi, e succede comunque. Passare oltre la finestra è il modo più comune in cui un risultato Critical arriva in produzione.
2. Avvia una Deep scan prima che qualcosa di reale vada online, e di nuovo dopo aver aggiunto il login, i pagamenti o qualsiasi tabella che contenga persone. Da sola non parte.
3. Pubblica.
4. Scansiona l’indirizzo pubblicato da fuori. La nostra legge la tua app online come farebbe un visitatore, richiede una ventina di secondi, non ha bisogno di un account e nomina i controlli che non è riuscita a finire: scansiona la tua app.

In quella sequenza c’è un buco, ed è quello con cui conviene fare i conti. La Quick scan gira quando pubblichi. La maggior parte di quello che apre una tabella non passa affatto dalla pubblicazione: cambi un’impostazione nel pannello Supabase, accetti a mezzanotte una policy che un assistente ti ha scritto in una finestra di chat, crei una tabella stamattina e lo schermo che la legge esce giovedì. Niente di tutto questo è una pubblicazione, quindi niente di tutto questo avvia una scansione, e la Deep scan non sarebbe comunque mai partita da sola.

Reeve Monitor fa la metà esterna nei giorni in cui non ti viene in mente. Ripassa tutti e nove i controlli ogni ora su un massimo di tre app, guarda se la tua app risponde almeno, ti dice quando un risultato cambia invece di aspettare che vada tu a guardare, e manda un rapporto a fine mese.

Leggere un risultato verde

Un risultato pulito vuol dire che ogni domanda che quella scansione poteva porre è tornata pulita il giorno in cui l’hai fatta. Vale qualcosa, e non è un verdetto sulla tua app.

Lovable mette la stessa riserva nella propria documentazione: gli strumenti aiutano a individuare problemi di sicurezza comuni e non possono garantire una sicurezza completa. Anche la nostra se la porta dietro, perché un controllo esterno automatico non è un audit e un elenco di risultati vuoto non è una garanzia.

L’unica regola da tenere per quando le due non coincidono: se la scansione dall’interno è pulita e una da fuori dice che una tabella ha risposto a una richiesta senza login, agisci sulla risposta da fuori. È la risposta che ricevono i tuoi utenti, ed è quella che riceve chiunque altro. Vai a leggere la policy di quella tabella.

Se la tua app sta su Supabase, la guida in parole semplici per questa piattaforma è la tua app Lovable è sicura, e i controlli scritti come comandi da eseguire tu stanno in il verificatore di sicurezza Supabase.

Cosa fare questa settimana

Se la tua app Lovable usa Supabase, apri una finestra di navigazione in incognito e scorri l’elenco sotto Authentication e Policies prima di venerdì. Chiunque può leggere il tuo database Supabase è lo stesso test scritto come comandi da incollare in un terminale.