I rischi di sicurezza del vibe coding, e come scoprirli prima dei vostri clienti

La risposta breve

È sicuro mettere online un'app che un'IA ha scritto da poche richieste? Non in base alla sola demo. Il "vibe coding", cioè l'abitudine di descrivere ciò che si vuole a parole proprie e lasciare che un assistente di IA produca il software, è un modo splendido per avere in fretta una prima versione. È anche un modo per accumulare problemi di sicurezza che nessuno ha deciso di creare e che nessuno ha cercato.

In questo articolo spieghiamo perché nascono, descriviamo i nove che incontriamo più spesso e chiudiamo con un criterio pratico per decidere se riparare o rifare. Noi stessi sviluppiamo software con assistenti di IA ogni settimana, quindi non è un discorso contro questi strumenti: è un invito a usarli a occhi aperti.

Cosa si intende per "vibe coding", e quando va benissimo

Il termine indica un modo di lavorare in cui la persona chiede una funzione a un assistente di IA in linguaggio comune, prova il risultato e continua a chiedere modifiche finché le sembra giusto. Il codice che ne esce non è detto che lo legga qualcuno. Il riscontro arriva dallo schermo: il pulsante funziona? La pagina ha l'aspetto previsto?

Per un prototipo usa e getta, un esperimento interno o una pagina che userete solo voi, è un compromesso ragionevole. L'errore costa poco e la velocità vale più della rifinitura. I guai cominciano quando il prototipo diventa, senza che nessuno lo decida, il prodotto: qualcuno aggiunge un accesso, si iscrivono i primi clienti, compare un modulo di pagamento, e il "rapido esperimento" custodisce ormai nomi, indirizzi email e denaro veri.

In questo percorso nessun passaggio impone una verifica di sicurezza. L'app non ha mai smesso di funzionare, quindi nessun allarme è mai suonato. È questo il problema centrale, e tutto il resto ne discende.

Perché il codice scritto dall'IA ha così spesso falle di sicurezza

I modelli di IA sono addestrati a produrre codice che fa ciò che si chiede. "Permetti agli utenti di scaricare le proprie fatture" è una richiesta chiara e verificabile. "Fai in modo che nessun utente possa mai scaricare la fattura di un altro" è una richiesta di tipo diverso: descrive qualcosa che non deve accadere, e una demo non mostra mai ciò che non accade. Se nessuno scrive la regola, non c'è motivo che il codice la faccia rispettare.

Diverse abitudini nell'uso di questi strumenti peggiorano le cose:

• Le decisioni di sicurezza si perdono per strada. In una lunga conversazione con l'assistente, un'istruzione iniziale come "solo il proprietario può modificare un record" può sparire quando una modifica successiva riscrive la stessa parte di codice. Nessuno se ne accorge, perché la funzione continua a funzionare.
• Le modifiche diventano troppo grandi per essere lette. Un assistente produce centinaia di righe in pochi secondi. Chi deve controllarle tende a scorrerle in fretta, e una rilettura veloce non è una revisione.
• La fiducia si accumula. Dopo dieci modifiche riuscite, l'undicesima riceve meno attenzione. Ci si rilassa proprio quando bisognerebbe controllare.
• L'assistente rivede il proprio lavoro. Chiedere allo strumento "è sicuro?" produce soprattutto rassicurazioni, perché condivide i punti ciechi di chi ha scritto il codice, che in questo caso è lui stesso.
• Le app nascono fuori dai canali normali. Chi lavora in amministrazione o nel marketing può costruire in un pomeriggio uno strumento funzionante e collegarlo ai dati aziendali senza avvisare nessuno.

Uno studio di settore molto citato, pubblicato nel 2025, ha provato un gran numero di campioni di codice scritti da modelli di IA e ha rilevato che una quota consistente, vicina alla metà in quello studio, conteneva una nota categoria di debolezza anche se il codice funzionava. I numeri cambiano da studio a studio e si spostano man mano che i modelli migliorano: considerateli un ordine di grandezza e verificate la fonte prima di citarli. Lo schema però è costante: funzionare e essere sicuri sono due proprietà distinte.

I nove problemi che vediamo più spesso

Ogni problema è descritto prima in parole semplici, poi con una breve nota su come nasce e come si scopre. Li abbiamo ordinati all'incirca in base a quanto spesso causano danni veri.

1. Segreti lasciati dove chiunque li può leggere

Ogni app usa dei segreti: la password del database, la chiave che le permette di inviare email, il codice che la collega a un servizio di pagamento. Gli assistenti li scrivono spesso direttamente nel codice, perché è la via più corta per ottenere qualcosa che parte. Quando il codice viene copiato in un archivio condiviso, su un server o in un browser, con lui si copiano anche i segreti.

La versione più pericolosa è quella del segreto che finisce nella parte di app inviata a ogni visitatore: chiunque apra gli strumenti per sviluppatori del browser lo legge. Programmi automatici setacciano la rete giorno e notte alla ricerca proprio di queste chiavi, e una chiave trapelata può essere usata nel giro di minuti. Per uno specialista trovare il problema è facile, e con strumenti gratuiti di scansione è rapido. Correggerlo richiede più che cancellare la riga: ogni chiave che sia stata esposta va sostituita, perché resta nella cronologia del codice.

2. Controlli dei permessi mancanti

È il problema più grave dell'elenco e il più difficile da vedere. L'accesso dimostra chi siete, ma non dice cosa potete fare. Un'app può gestire alla perfezione la prima parte e dimenticare la seconda: se l'indirizzo della vostra fattura contiene un numero e cambiandolo compare la fattura di un altro, l'app ha una falla nel controllo degli accessi.

Gli assistenti perdono facilmente questi controlli. Ogni schermata e ogni azione richiedono la propria domanda, "questa persona è proprietaria di questo dato?", e quando il codice viene riscritto molte volte alcune domande scompaiono. Una demo con un solo utente di prova non lo rivela mai. Emerge soltanto provando con due utenti, o con un utente e un amministratore, e cercando di oltrepassare il limite di proposito.

3. Fidarsi di ciò che scrivono gli utenti

Tutto ciò che arriva dall'esterno, un campo di un modulo, un indirizzo, un file caricato, può contenere istruzioni travestite da dati. Se l'app costruisce una richiesta al database incollandoci dentro il testo dell'utente, un visitatore abile può cambiare la richiesta e leggere o cancellare ciò che non dovrebbe toccare. Se mostra in pagina il testo degli utenti senza ripulirlo, un visitatore può inserire uno script che poi gira nei browser degli altri.

Sono problemi antichi, con rimedi noti, e gli assistenti conoscono i rimedi. Semplicemente non li applicano sempre, soprattutto nelle parti scritte in fretta, "basta che funzioni". La correzione è quasi meccanica: usare il modo sicuro di interrogare il database, ripulire tutto ciò che viene mostrato e controllare ogni dato in ingresso sul server, non solo nel browser.

4. Componenti software che non esistono

Le app moderne sono fatte di centinaia di componenti già pronti. Quando un assistente ne ha bisogno, a volte inventa un nome plausibile per un componente che non esiste. Chi attacca lo sa: registra i nomi inventati e li riempie di codice dannoso, così la prossima persona che accetta il suggerimento lo installa senza pensarci. La tecnica ha ormai un nome proprio e funziona perché il pacchetto pericoloso è identico a uno legittimo.

La difesa è noiosa ma efficace: verificare che ogni componente sia reale, diffuso e proveniente dalla fonte ufficiale; bloccarne la versione perché non possa cambiare di nascosto; eseguire periodicamente una scansione dei componenti con debolezze note. Un breve elenco aggiornato di ciò di cui è fatta l'app vale più di qualsiasi strumento.

5. Controlli di sicurezza che sembrano controlli

Per far funzionare una funzione, a volte un assistente scrive un segnaposto: una funzione chiamata "verifica permesso" che risponde sempre di sì, un accesso che durante i test accetta qualunque password, una nota che dice "da fare: validare". Di solito il segnaposto dovrebbe essere sostituito. Se nessuno legge il codice, non lo è.

Sono facili da trovare se qualcuno li cerca e quasi impossibili da trovare se nessuno lo fa. Una lettura riga per riga, fatta da una persona, delle parti che gestiscono accessi, pagamenti e dati personali ne individua quasi tutti.

6. Porte lasciate aperte: pagine di amministrazione e limiti assenti

Gli assistenti creano spesso comodità accessorie: una pagina di amministrazione, un indirizzo di prova, un percorso che elenca tutti gli utenti. In fase di sviluppo sono utili. In produzione, se sono raggiungibili e non protetti, consegnano le chiavi. Lo stesso vale per i limiti mancanti: un modulo di accesso che permette a un programma di provare diecimila password al minuto, un modulo di contatto che si può usare per spedire spam senza fine, una ricerca che si può usare per sovraccaricare il server.

Nessuno dei due problemi emerge usando l'app in modo normale. Entrambi compaiono subito quando qualcuno che non è gentile la mette alla prova. Il rimedio è elencare ogni indirizzo a cui l'app risponde, decidere chi può raggiungerlo e mettere limiti ragionevoli a tutto ciò che un programma potrebbe ripetere.

7. Istruzioni nascoste rivolte all'assistente stesso

I gruppi che lavorano con assistenti di IA condividono spesso piccoli file di configurazione che dicono all'assistente come comportarsi: stile del codice, librerie preferite, regole. Quei file sono un bersaglio. Si possono nascondere istruzioni al loro interno con caratteri invisibili, così che il file sembri innocuo a una persona ma ordini all'assistente di aggiungere una debolezza, scaricare qualcosa da internet o saltare un controllo. Lo stesso trucco si può usare attraverso documenti o pagine web che all'assistente viene chiesto di leggere.

Questo problema non si vede a occhio, ed è proprio il suo scopo. Si affronta trattando quei file come codice: rivedere ogni modifica, accettarle solo da persone note e usare strumenti che rivelano i caratteri nascosti. È anche un buon motivo per non lasciare che un assistente agisca senza supervisione sul contenuto preso da internet.

8. Gestione pericolosa di file e formati di dati

Le app leggono e scrivono molti tipi di file e di dati. Alcuni formati sono rischiosi di natura: leggere un file nel modo sbagliato può permettergli di eseguire codice sul vostro server, e trattare immagini, fogli di calcolo o archivi senza limiti può mandare in crash l'app o esporre altri file della macchina. Queste falle stanno nelle fondamenta, non hanno un sintomo visibile all'utente e sono proprio il genere di cosa che un assistente riproduce dagli esempi che ha visto.

Accettare solo i tipi di file previsti, limitarne la dimensione, non aprire mai un file caricato con qualcosa che possa eseguirlo e tenere i caricamenti lontani dalla parte del server che fa girare l'app. Il resto lo trova una revisione specialistica.

9. Uso disinvolto dei dati personali

Il nono problema non sta nel codice ma nel modo di lavorare. Dati veri di clienti vengono incollati in un assistente "per avere una prova realistica". Una copia del database in uso serve per lo sviluppo. I registri annotano richieste intere, comprese password o dati di carte. I backup stanno non cifrati in una cartella che chiunque può aprire.

Per un'azienda è il punto in cui un errore tecnico diventa un errore legale. I dati personali sono protetti dalla legge, nel Regno Unito come nell'Unione Europea, e gli obblighi valgono per un prototipo come per un prodotto finito. La regola semplice è che gli ambienti di prova usano dati inventati e i dati veri vanno solo dove ci sono protezioni vere.

Cosa significa per la vostra azienda

Se non siete sviluppatori, vale la pena tenere a mente tre conseguenze.

Primo, i vostri clienti lo chiederanno. I clienti più grandi inviano sempre più spesso questionari sulla sicurezza prima di firmare, e vogliono sapere chi ha costruito il software, come è stato controllato e dove stanno i dati. Un'app che non è mai stata rivista non può rispondere con sincerità.

Secondo, una violazione costa in modi che col codice c'entrano poco. Potreste dover avvisare l'autorità per la protezione dei dati e le persone coinvolte, spenderete tempo e denaro per indagare, e la fiducia richiede molto più tempo per essere ricostruita di quanto ne serva per correggere il software. Per una piccola impresa il danno di immagine pesa spesso più della sanzione.

Terzo, la responsabilità non passa allo strumento. Se la falla l'ha scritta un'IA, a pubblicarla siete stati voi. "L'ha fatto l'assistente" non regge né con un cliente né con un'autorità.

Come scoprire se la vostra app ha questi problemi

Si può imparare molto senza leggere una riga di codice. Cinque domande, rivolte a chi ha costruito l'app, distinguono chi è preparato da chi spera:

• Dove sono conservate password e chiavi, e qualcuna è mai stata nel codice condiviso?
• Se creo due account normali, uno dei due riesce a raggiungere i dati dell'altro cambiando qualcosa nell'indirizzo?
• Quali pagine e indirizzi esistono che un utente normale non vede mai, e chi può aprirli?
• Di cosa è fatta l'app, e quando sono stati controllati quei componenti l'ultima volta?
• Ci sono dati veri di clienti fuori dal sistema in uso, in prove, copie o registri?

Per una verifica seria, la revisione indipendente deve guardare l'applicazione in funzione come farebbe un estraneo. Leggere il codice trova alcuni problemi, ma permessi, pagine nascoste e limiti deboli si scoprono meglio provando: entrando come persone diverse, alterando le richieste, facendo scadere le sessioni e dando ai moduli dati inattesi. Un problema si considera chiuso solo quando la stessa prova non riesce più.

Gli scanner automatici sono un buon primo passaggio. Sono bravi a trovare chiavi esposte e componenti con debolezze note, e scarsi sui problemi che dipendono da come funziona la vostra azienda, per esempio chi può vedere quale fattura. Quel secondo gruppo richiede una persona che capisca le vostre regole.

Riparare o rifare?

Una volta trovati i problemi, la domanda pratica è se rattoppare l'app o rifare la parte coinvolta. Un buon criterio nasce da una sola domanda: tutte le decisioni su "chi può fare cosa" si possono descrivere in un unico punto?

• Riparare quando i problemi sono locali: una chiave da sostituire, una richiesta da correggere, un componente da aggiornare, una pagina non protetta da chiudere. Ogni correzione è piccola e indipendente.
• Rifare lo strato dei permessi quando i controlli sono sparsi in decine di schermate senza uno schema. Sistemarli uno a uno è lento, e una sola schermata dimenticata vi riporta al punto di partenza. Una regola centrale che ogni schermata consulta è più sicura e più economica da mantenere.
• Rifare lo strato dei dati quando l'app serve più clienti con un solo database e non è mai stata pensata per tenerli separati. Una separazione aggiunta dopo è fragile.
• Valutare di ricominciare quando nessuno, nemmeno chi l'ha costruita, sa spiegare come funziona. Un codice che nessuno capisce non si può rendere affidabile, solo sperare.

Nell'ultimo caso il prototipo non è sprecato. È un'ottima specifica: mostra esattamente cosa è piaciuto e cosa devono fare le schermate. La nuova versione conserva quella conoscenza e la costruisce su basi progettate invece che accumulate.

Evitare che si ripeta

L'obiettivo non è smettere di usare gli assistenti di IA, ma circondarli di poche abitudini economiche.

• Scrivere le regole di sicurezza prima di chiedere la funzione. Chi può vederlo? Cosa si può scrivere qui? Cosa non va mai salvato? Un breve elenco nella richiesta cambia il risultato in modo sensibile.
• Tenere le modifiche piccole. Una modifica che si legge in dieci minuti si può rivedere. Una che non si legge non verrà rivista.
• Trattare il codice generato come proveniente da uno sconosciuto. Può essere ottimo, ma si controlla prima di fidarsene, soprattutto attorno ad accessi, denaro e dati personali.
• Automatizzare i controlli noiosi. Scansione dei segreti, dei componenti e analisi statica possono girare a ogni modifica e non si stancano mai.
• Provare l'app in funzione con ruoli diversi. È l'abitudine più preziosa e quella saltata più spesso.
• Tenere i dati veri fuori dagli esperimenti. Dati inventati per le prove, dati veri solo nel sistema in uso.

Come lavoriamo noi con gli assistenti di IA

Usiamo ogni giorno assistenti di IA per costruire software e non vorremmo tornare indietro. Trattiamo però ciò che producono come una bozza veloce di un collega molto rapido e un po' junior: utile, instancabile e bisognosa di un secondo paio d'occhi. Ogni decisione di progetto è di una persona, una persona legge tutto ciò che sta vicino a accessi, pagamenti e dati personali, e l'applicazione finita viene provata come la proverebbe un estraneo. I dati dei clienti non entrano nei nostri assistenti né nelle copie di prova.

Non abbiamo un confronto nostro da citare e preferiamo dirlo piuttosto che inventarlo. Possiamo dire che le abitudini descritte sono economiche, che sono quelle che applichiamo ai nostri prodotti e che i problemi che evitano sono quelli che costano di più agli altri. Se avete già un'app costruita così e avete dei dubbi, il primo passo è una verifica indipendente dell'applicazione in funzione. Ci facciamo volentieri carico di questa verifica, e vi diremo con chiarezza cosa va bene e cosa no.

Domande frequenti

Foto: FlyD su Unsplash