La tua app fatta con Lovable è sicura? 7 controlli da fare prima del lancio

Strumenti come Lovable, Cursor e Bolt sono ottimi per partire: in pochi giorni passi da un'idea a un'app che funziona davvero. Il problema arriva dopo. L'AI scrive codice che funziona nel caso ideale, ma non sempre aggiunge i controlli che servono quando arrivano utenti veri. E la sicurezza è la parte che si vede meno: l'app va benissimo, finché qualcuno non apre gli strumenti per sviluppatori del browser.

Nel codice delle app fatte con l'AI che leggo, i problemi di sicurezza sono i più frequenti. Ecco i sette controlli che farei prima di lanciare, in ordine di urgenza. Alcuni li puoi fare in autonomia, per altri serve uno sviluppatore.

1. Nessuna chiave segreta nel browser

Tutto quello che sta nel codice del frontend arriva al browser di chi visita il sito. Anche le variabili d'ambiente con prefisso VITE_ o NEXT_PUBLIC_: finiscono nel JavaScript scaricato, leggibili da chiunque.

Se lì dentro c'è la chiave di OpenAI, chiunque può usarla a tue spese.

Come controllare: apri il sito, premi F12, vai nella scheda dei sorgenti e cerca sk- o il nome del servizio. Come si risolve: le chiamate che usano chiavi segrete si spostano in una funzione lato server (per esempio una Edge Function di Supabase), dove la chiave non esce mai.

2. La chiave di servizio di Supabase non sta né nel frontend né nel repository

Supabase ha due chiavi. Quella pubblica (anon) è fatta per stare nel browser. Quella di servizio (service_role) invece salta tutte le regole di accesso: chi ce l'ha può leggere, modificare e cancellare tutto.

Come controllare: cerca service_role nel codice del frontend e nel repository, compresa la storia dei commit. Se la trovi: rigenerala dal pannello di Supabase, aggiorna le funzioni server che la usano e toglila dal codice. Cancellarla dal file non basta: resta nella storia.

3. Ogni tabella ha le sue regole di accesso

Visto che la chiave pubblica è davvero pubblica, l'unica cosa che protegge i dati sono le regole di accesso del database (Row Level Security). Una tabella senza regole è leggibile e modificabile da chiunque abbia quella chiave, cioè da chiunque visiti il sito.

Come controllare: nel pannello di Supabase guarda quali tabelle hanno le regole disattivate; anche il Security Advisor le segnala. Poi controlla che le regole non siano «vero per tutti».

4. I file caricati non sono pubblici se non devono esserlo

Documenti, curriculum, fatture: se stanno in un contenitore pubblico, chi ha il link li scarica, anche senza essere registrato.

Come controllare: guarda le impostazioni dei contenitori di file (bucket). Per i documenti privati serve un contenitore privato e link temporanei generati dal server.

5. Il pannello di amministrazione è protetto, non solo nascosto

Nascondere un pulsante o una pagina nel frontend non è una protezione. Se le operazioni da amministratore sono permesse dal database o dal server a qualunque utente registrato, basta chiamarle direttamente.

Come controllare: entra con un utente normale e prova ad aprire l'indirizzo della pagina admin, o a ripetere una sua operazione. Il controllo deve stare nelle regole del database o sul server.

6. Il piano a pagamento non si sblocca dal browser

Se l'informazione «questo utente ha pagato» sta in una colonna che l'utente può modificare, o se il controllo è solo nel frontend, il piano Pro si sblocca senza pagare.

Come si risolve: lo stato del pagamento lo scrive solo il server, per esempio quando arriva la conferma di Stripe, e l'utente non può modificarlo.

7. Niente modalità debug in produzione

I messaggi d'errore dettagliati sono utili mentre sviluppi. In produzione raccontano a chiunque come è fatto il tuo server: percorsi, nomi delle tabelle, a volte parti delle query.

Come controllare: provoca un errore (per esempio un indirizzo che non esiste o un modulo compilato male) e guarda cosa compare.

Se anche uno solo di questi punti ti lascia un dubbio

Non succede solo a te: sono i problemi che trovo più spesso. Nessuno di questi rende la tua app un cattivo prodotto. Vuol dire solo che prima di aprirla a utenti veri, qualcuno deve rileggere il codice con occhi diversi da quelli dell'AI che l'ha scritto.

Vuoi che lo controlli io? Con il Check-up Codice AI leggo il codice della tua app e ti dico cosa è rotto, cosa è pericoloso e quanto costa sistemarlo. Prezzo fisso, NDA prima dell'accesso. Scopri il Check-up Codice AI