La mia app Lovable è sicura? Checklist di sicurezza pre-lancio

«La mia app Lovable è sicura?» è la domanda giusta da farsi prima di aprire l'app al pubblico. La risposta onesta è: dipende da una manciata di punti che l'AI tende a trascurare, e che puoi controllare prima del lancio. Questa checklist di sicurezza vale per qualsiasi app creata con l'AI, che tu abbia usato Lovable, Bolt, Replit, Cursor o un altro strumento. Per ogni punto ti diciamo cosa controllare e come farlo.

Perché un'app che funziona non è per forza sicura

Quando costruisci con l'AI, provi l'app come la userebbe un cliente normale: registrazione, login, acquisto. Se tutto fila, sembra pronta. La sicurezza però riguarda l'altro lato: cosa succede se qualcuno fa cose che non avevi previsto.

Pensa a una casa con la porta che si apre e si chiude perfettamente, ma senza serratura. Funziona, ma non è sicura. Molti problemi delle app fatte con intelligenza artificiale sono di questo tipo: niente si rompe, ma qualcosa resta aperto.

Non serve essere un bersaglio famoso per avere problemi. Esistono programmi automatici che scandagliano il web in cerca di configurazioni deboli note, senza guardare chi c'è dietro. Un'app piccola ma aperta è un bersaglio comodo quanto una grande.

La checklist di sicurezza prima del lancio

Abbiamo raggruppato i controlli per area. Non serve essere programmatori per farne la maggior parte.

Chiavi e segreti

1. Nessuna chiave segreta nel frontend. Il frontend è la parte dell'app che gira nel browser: tutto quello che contiene è leggibile da chiunque. Chiavi di OpenAI, Stripe segrete o la chiave di servizio di Supabase non devono stare lì. Trovi come verificarlo nella guida sulle chiavi API esposte nel frontend.
2. Segreti salvati nel posto giusto. Le chiavi vanno nelle impostazioni dei segreti della piattaforma o nelle variabili d'ambiente del server. Il file .env non deve essere nel repository su GitHub.

Database e file

1. Regole di accesso attive su ogni tabella. Se usi Supabase, ogni tabella deve avere la RLS attiva e regole che lasciano passare solo chi deve. Una regola che lascia passare tutti equivale a nessuna regola. Ne parliamo in dettaglio nell'articolo sulla RLS di Supabase e i dati esposti.
2. File privati in spazi privati. Documenti, foto profilo, fatture: lo spazio dove sono salvati non deve essere pubblico, se contiene dati personali.
3. Backup attivi e provati. Un backup che non hai mai provato a ripristinare è una speranza, non un backup.

Login e permessi

1. Pagine riservate protette davvero. Nascondere un pulsante non basta. Il controllo deve avvenire «lato server», cioè sul server o nel database, non solo nell'interfaccia che l'utente può manipolare.
2. Ruolo di admin non modificabile dall'utente. Se l'app decide chi è admin leggendo un campo del profilo che l'utente può cambiare, chiunque può diventare admin.
3. Login, conferma email e reset password funzionanti in produzione. I link nelle email devono puntare al dominio reale, non all'anteprima. Se qualcosa non va, consulta la guida sugli errori di login e autenticazione.

Dati inviati dagli utenti e funzioni a consumo

1. Controlli sui dati inviati. Moduli e campi vanno verificati anche lato server: lunghezze massime, formati, campi obbligatori. Mai fidarsi di un prezzo o di uno sconto calcolato nel browser.
2. Funzioni che costano protette. Generazione con AI, invio di email o SMS: devono richiedere il login e avere un limite di utilizzo (in gergo rate limit, cioè un numero massimo di richieste in un certo tempo). Altrimenti qualcuno può consumare il tuo budget.

Pagamenti

1. Pagamento confermato dal fornitore, non dalla pagina di ringraziamento. Se l'ordine risulta pagato solo perché l'utente è arrivato sulla pagina «grazie», basta digitare quell'indirizzo per non pagare. La conferma deve arrivare da un webhook, cioè un messaggio che il servizio di pagamento invia direttamente al tuo server.

Configurazione e privacy

1. Dipendenze senza vulnerabilità gravi note. Le dipendenze sono le librerie di codice scritte da altri che la tua app usa. Gli strumenti di controllo segnalano quelle con problemi noti, per esempio il comando npm audit.
2. HTTPS attivo e nessun messaggio di errore tecnico mostrato agli utenti. Gli errori dettagliati aiutano te, ma anche chi cerca punti deboli.
3. Privacy in ordine. Informativa privacy, cookie banner se serve, dati in fornitori adeguati. Trovi i principi nella guida sul GDPR per app create con l'AI.

Come verificare i punti più importanti da solo

Ecco una tabella che collega ogni controllo a una verifica pratica.

Qualche consiglio pratico per fare le prove:

• Crea almeno due account di prova, con dati diversi, e prova a «scambiarti» i dati cambiando gli identificativi negli indirizzi delle pagine.
• Usa sempre una finestra in incognito per simulare un visitatore anonimo.
• Esegui lo scanner della tua piattaforma, se ce l'ha. Lovable, per esempio, esegue un controllo prima della pubblicazione e ne offre uno più approfondito su richiesta.
• Puoi chiedere all'AI una revisione mirata, per esempio: «Elenca tutte le chiamate al database fatte dal frontend e, per ognuna, quale regola RLS la protegge». Usa la risposta come punto di partenza, non come verdetto.

Fai queste prove solo sulla tua app.

Cosa fare se trovi un problema

Non tutti i problemi hanno la stessa urgenza. Questo è l'ordine che seguiamo di solito:

1. Chiavi segrete esposte: revoca, sostituzione e spostamento lato server.
2. Dati personali accessibili ad altri: regole di accesso al database e ai file.
3. Pagamenti e funzioni a consumo: webhook e limiti di utilizzo.
4. Permessi e pagine riservate: controlli lato server.
5. Tutto il resto: dipendenze, messaggi di errore, rifiniture.

Quando chiedi all'AI di correggere un problema di sicurezza, descrivi il risultato che vuoi, non solo l'errore da far sparire. Per esempio: «Gli utenti devono vedere solo i propri ordini, anche se modificano l'indirizzo della pagina». Altrimenti la correzione più rapida può essere proprio quella che toglie la protezione.

Dopo ogni correzione, ripeti la verifica che aveva fatto emergere il problema. Una regola nuova può chiudere un buco e, allo stesso tempo, bloccare una funzione legittima: meglio accorgersene tu che i tuoi utenti.

Se i problemi più gravi riguardano un'app già online con utenti reali, valuta se qualcuno può aver avuto accesso ai dati. In alcuni casi il GDPR prevede obblighi di notifica precisi, ed è il momento di sentire un professionista.

Quando conviene farti aiutare

Questa checklist ti permette di trovare i problemi più comuni. Sistemarli è un'altra storia: a volte basta una regola, a volte serve spostare una parte della logica sul server, e l'AI può peggiorare le cose se non sa esattamente cosa fare.

Se vuoi un secondo paio d'occhi prima del lancio, di solito facciamo una revisione di sicurezza completa e sistemiamo quello che troviamo. Per capire se ti serve, prenota una call gratuita.