Un agente AI scrive in pochi minuti un’app che funziona. Funziona nel senso che si apre, risponde, salva i dati. Se sia anche sicura è un’altra domanda, e il modello non se la pone da solo a meno che tu non gliela faccia. Se stai per mettere online qualcosa nato da un prompt, questa è la lista che usiamo noi prima del via libera.
Non è un audit di sicurezza e non lo sostituisce. È il minimo che separa un prototipo da qualcosa che un utente vero può toccare.
Perché il codice “che funziona” non basta
Un modello di linguaggio produce il codice più probabile per la richiesta che riceve. Se chiedi “fammi un login”, ottieni un login. Non ottieni, per default, il limite ai tentativi, il controllo su chi può leggere i dati degli altri utenti o la gestione corretta dei segreti. Sono tutte cose che non compaiono nella richiesta, quindi non compaiono nel risultato.
Nella nostra esperienza il difetto più frequente non è un errore clamoroso. È una dimenticanza: un percorso che nessuno ha pensato di proteggere perché nessuno lo aveva chiesto.
1. Nessun segreto dentro il codice
Chiavi di accesso alle API, password del database, token: devono stare in variabili d’ambiente o in un gestore di segreti, mai nel repository. Cerca nel progetto stringhe lunghe e casuali, e controlla che il file con le variabili sia escluso dal controllo di versione. Se una chiave è già finita in un commit pubblico, non basta cancellarla dal file: va revocata e rigenerata, perché la cronologia resta consultabile.
2. Dipendenze: esistono davvero e le usa qualcuno?
Gli agenti a volte propongono pacchetti con nomi plausibili ma inesistenti, oppure poco mantenuti. Prima di installare qualcosa che non conosci, apri la pagina ufficiale del pacchetto: chi lo mantiene, quando è stato aggiornato l’ultima volta, quante persone lo usano. Un nome inventato che qualcuno ha poi registrato con intenzioni cattive è un rischio concreto, non teorico.
3. Ogni input è un nemico finché non dimostra il contrario
Qualunque campo compilato da un utente va validato lato server, non solo nel browser. Controlla soprattutto due cose: che le query al database usino parametri e non stringhe incollate, e che il testo mostrato in pagina venga ripulito prima di essere stampato. Sono le due porte da cui entrano le vulnerabilità più note, quelle che l’OWASP elenca da anni nella sua classifica dei rischi per le applicazioni web.
4. Autenticazione e autorizzazione sono due problemi diversi
Sapere chi sei non è lo stesso che sapere cosa puoi vedere. Un errore classico: l’utente è loggato, quindi può aprire anche l’indirizzo con l’identificativo di un altro utente. Prova a cambiare a mano un numero nell’URL. Se vedi i dati di qualcun altro, l’app non è pronta.
Per il login, non farti scrivere un sistema da zero se esiste una soluzione collaudata del tuo framework. Meno codice tuo, meno posti dove sbagliare.
5. Dati personali: dove finiscono?
Se l’app tratta dati di persone, entra in gioco il GDPR, cioè il regolamento europeo 2016/679. Tre domande pratiche: quali dati raccogli davvero, dove sono conservati, chi può leggerli. E una quarta che si dimentica: quei dati finiscono anche nei prompt che mandi allo strumento di AI mentre lavori? Controlla le impostazioni dell’abbonamento sull’uso dei contenuti per l’addestramento, e non incollare mai dati reali dei clienti per “far capire il problema” all’agente.
6. Errori e log senza fughe di informazioni
Una pagina di errore che mostra il percorso dei file o il testo di una query regala a chi attacca una mappa. In produzione l’utente vede un messaggio generico, e i dettagli vanno in un log che solo tu leggi. Controlla che la modalità di debug sia spenta.
7. Limiti, backup e un piano per quando va storto
Mettere un limite alle richieste per indirizzo evita che un modulo di contatto diventi un rubinetto di spam o di costi. Poi il backup: esiste, è automatico, e hai provato almeno una volta a ripristinarlo? Un backup mai ripristinato è una speranza, non un backup.
8. Una seconda lettura fatta da un umano
Chiedi a una persona, o a un secondo agente con istruzioni diverse, di leggere il codice cercando solo problemi di sicurezza. Non quello che l’ha scritto: chi ha generato il codice tende a ritenerlo corretto. Abbiamo notato che una revisione “ostile” trova cose che la prima generazione non vede, soprattutto sui permessi.
Cosa fare se hai poco tempo
Se puoi fare solo tre cose, falle in quest’ordine: togli i segreti dal codice, prova il cambio di identificativo nell’URL, spegni il debug. Coprono una quota enorme dei guai reali.
Per capire quanto debito si accumula quando si salta questa fase, leggi anche i segnali del debito tecnico da vibe coding. Per i casi in cui conviene o no delegare tutto all’agente c’è la guida su cos’è il vibe coding, mentre se stai scegliendo lo strumento ti serve il confronto tra Cursor e Claude Code.
Domande frequenti
Il codice scritto da un’AI è meno sicuro di quello scritto da una persona?
Non in modo automatico. Il problema è che nessuno lo rilegge con attenzione perché “ha funzionato subito”. Il codice scritto a mano senza revisione ha gli stessi rischi: cambia solo la velocità con cui li accumuli.
Posso usare il vibe coding per un’app che tratta dati dei clienti?
Sì, a patto di rispettare le regole che valgono per qualunque software: dati minimi, accessi controllati, informativa corretta e una revisione umana prima del lancio. Per dati sensibili o sanitari conviene far valutare il progetto a un professionista della protezione dei dati.
Quanto tempo richiede questa verifica?
Per un’app piccola, una mezza giornata ben usata copre gli otto punti. Per un’app con pagamenti o dati delicati serve una verifica più profonda, fatta da chi lo fa di mestiere.
E tu, l’ultima volta che hai messo online qualcosa nato da un prompt, quale di questi otto controlli hai saltato?