Immagina questa scena, che oggi si ripete in molte aziende. Un collaboratore volenteroso, senza una formazione da sviluppatore, ha costruito in un fine settimana uno strumento per gestire gli ordini del reparto: l'ha descritto a un assistente di intelligenza artificiale, ha incollato il codice che gli veniva proposto, e il programma funziona. Dal lunedì lo usano in otto. A marzo ci sono i dati di duecento clienti, i prezzi di listino e i margini. A giugno qualcuno chiede: "ma è sicuro?". Nessuno sa rispondere, perché nessuno ha mai guardato.
Questa guida è per chi si trova in quella situazione, o vuole evitarla. Spiega cosa si intende per vibe coding, quali sono i rischi di sicurezza tipici delle applicazioni generate così, come riconoscerli senza essere un tecnico, quali domande fare, come si verifica una app in sette passi e quando conviene correggere o rifare. Non è una guida contro l'intelligenza artificiale: è una guida per usarla senza trasformare un'idea utile in un problema.
Cos'è il vibe coding
Il termine descrive un modo di sviluppare software in cui si descrive a un assistente di IA ciò che si vuole, si accetta il codice proposto e si procede "a sensazione" (vibe, appunto), senza leggerlo o comprenderlo in dettaglio. Se qualcosa non funziona, si incolla l'errore nella chat e si prova la correzione successiva.
È un metodo con meriti reali: permette a chi non programma di costruire prototipi, strumenti personali, dimostrazioni. Per esplorare un'idea o fare un esperimento è straordinario.
Il problema nasce da un passaggio silenzioso: quello strumento nato per provare diventa, per inerzia, uno strumento di lavoro. Non c'è mai un momento in cui qualcuno decide "ora è un sistema aziendale, quindi lo trattiamo come tale". Succede e basta, e con esso arrivano dati reali, utenti reali, e la possibilità di danni reali.
Una distinzione utile prima di proseguire:
| Uso | Esempio | Il vibe coding va bene? |
|---|---|---|
| Personale, senza dati altrui | Un calcolatore per le proprie spese | Sì |
| Prototipo da mostrare | Una dimostrazione per discutere un'idea con il team | Sì, se resta un prototipo |
| Interno, con pochi utenti e dati non sensibili | Un elenco condiviso di attività | Con cautela, dopo una verifica |
| Con dati di clienti, dipendenti o fornitori | Un gestionale, un'area clienti | No, senza verifica professionale |
| Esposto su internet o con pagamenti | Un sito di prenotazioni, un portale | No, senza progettazione e verifica |
Perché il codice generato è spesso insicuro (senza colpe)
Non è una questione di cattiva volontà né di strumenti difettosi. Ci sono ragioni strutturali, utili da conoscere per capire dove guardare.
L'IA è ottimizzata per far funzionare, non per proteggere. Un assistente produce la risposta che soddisfa la richiesta: "fammi un login", "fammi un elenco ordini". Se la sicurezza non viene chiesta, tende a non esserci, o a esserci nella forma più semplice.
Non conosce il tuo contesto. Non sa quali dati sono riservati, chi può vedere cosa, quali obblighi di legge valgono per te. Produce codice tipico, non codice adatto.
Le richieste si accumulano senza un disegno. Ogni aggiunta viene chiesta in una conversazione diversa. Il risultato è un insieme di parti che funzionano, senza che nessuno ne abbia verificato la coerenza.
Nessuno rilegge. Chi non sa programmare non può valutare il codice; chi sa programmare, davanti a mille righe prodotte in pochi secondi, tende a fidarsi di ciò che "gira".
Non c'è un responsabile. Lo strumento è nato fuori dai canali dell'azienda: nessun reparto IT lo conosce, nessuno lo mantiene, nessuno lo aggiorna.
I dati disponibili sono coerenti con questo quadro. Nel suo rapporto del 2025 sulla sicurezza del codice generato dall'IA, la società di sicurezza Veracode ha messo alla prova più di cento modelli su 80 compiti di programmazione: nel 45% dei casi il codice prodotto conteneva una vulnerabilità, e i modelli più grandi non andavano sensibilmente meglio di quelli piccoli (sintesi su SD Times). È uno studio, con i suoi limiti di metodo, ma l'ordine di grandezza è quello che osservano molti professionisti: l'IA produce codice che funziona, non codice sicuro per impostazione predefinita.
Gli otto rischi che incontri più spesso
Per ciascun rischio: cos'è, come si manifesta in pratica, cosa chiedere.
1. Password e chiavi scritte nel codice
Cos'è. Per collegarsi a un database, a un servizio di posta o a un'IA, un programma ha bisogno di credenziali. L'assistente, per far funzionare l'esempio, le scrive direttamente nel codice. Se quel codice finisce in un archivio condiviso, o viene pubblicato, le credenziali sono pubbliche.
Come si manifesta. Esistono strumenti automatici che scandagliano di continuo gli archivi di codice pubblici in cerca di chiavi esposte, e una chiave trovata può essere sfruttata molto in fretta: dati copiati, servizi a pagamento consumati, e la fattura la riceve il proprietario.
Cosa chiedere. "Dove sono conservate le password e le chiavi? Sono nel codice o in un luogo protetto? Sono mai finite in un archivio condiviso o pubblico? Se sì, sono state cambiate?"
2. Controllo degli accessi: vedere i dati di un altro
Cos'è. L'app dovrebbe decidere, a ogni richiesta, se questo utente può vedere questi dati. Spesso controlla solo che l'utente sia entrato, non cosa può vedere.
Come si manifesta. Un cliente apre il proprio ordine e nell'indirizzo c'è un numero. Cambia il numero e vede l'ordine di un altro cliente. È uno degli errori più frequenti e più gravi: nella classifica dei rischi per le applicazioni web di OWASP, l'organizzazione di riferimento del settore, il controllo degli accessi difettoso è la prima categoria (OWASP Top 10).
Cosa chiedere. "Se un utente modifica un numero nell'indirizzo, riesce a vedere i dati di un altro? Qualcuno ha provato? Dove sono definiti i permessi: nell'interfaccia o anche sul server?"
3. Dati inseriti e non controllati
Cos'è. Ogni campo di un modulo può essere usato per inserire non solo dati, ma comandi. Un programma che non controlla ciò che riceve può essere indotto a eseguire azioni non previste: leggere un database intero, mostrare contenuti altrui, bloccarsi.
Come si manifesta. Un campo "cerca" che, con un testo particolare, restituisce tutta la tabella dei clienti; un commento che, visto da un altro utente, esegue codice nel suo browser.
Cosa chiedere. "Come vengono controllati e ripuliti i dati inseriti? Qualcuno ha provato i test più comuni?" Nel rapporto Veracode citato, la protezione da questo tipo di attacco era tra le più carenti nel codice generato.
4. Dati personali e GDPR
Cos'è. Se l'app tratta dati di persone (nomi, email, telefoni, dati di dipendenti), valgono gli obblighi del GDPR. Una delle conseguenze pratiche: in caso di violazione dei dati personali, il titolare del trattamento deve, di regola, notificarla all'autorità di controllo (in Italia, il Garante per la protezione dei dati personali) entro 72 ore da quando ne è venuto a conoscenza, salvo che sia improbabile un rischio per le persone; se il rischio è elevato, vanno avvisati anche gli interessati. Ogni violazione va inoltre documentata in un registro interno.
Come si manifesta. Un'app con dati di clienti esposta per mesi senza che nessuno se ne accorga; quando emerge, l'azienda scopre di non avere né un registro né una procedura.
Cosa chiedere. "Quali dati personali tratta? Dove sono conservati, per quanto tempo, chi può accedervi? Abbiamo una procedura se si verifica una violazione?" Per le valutazioni giuridiche, rivolgiti al tuo consulente o al responsabile della protezione dei dati: questa guida non è consulenza legale.
5. Librerie inventate o non aggiornate
Cos'è. Il software moderno si costruisce con componenti esterni (librerie). Gli assistenti di IA, a volte, suggeriscono componenti che non esistono: nomi plausibili ma inventati. Un malintenzionato può registrare un componente con quel nome, contenente codice dannoso, in attesa che qualcuno lo installi seguendo il suggerimento. In altri casi i componenti esistono, ma sono vecchi, con falle già note.
Come si manifesta. L'app funziona, ma include un componente sconosciuto che invia dati all'esterno, oppure una libreria con una falla pubblicata da anni.
Cosa chiedere. "Mi dai l'elenco di tutti i componenti esterni usati, con versione e origine? Qualcuno ha verificato che esistano davvero, siano diffusi e siano aggiornati?"
6. Messaggi di errore che rivelano troppo
Cos'è. Quando qualcosa va storto, un programma ben fatto mostra all'utente un messaggio generico e registra i dettagli in un luogo riservato. Un programma generato in fretta spesso mostra il dettaglio tecnico: percorsi dei file, nomi delle tabelle, a volte pezzi di configurazione.
Come si manifesta. Un errore, visibile a chiunque, che descrive come è fatto il sistema interno: informazioni preziose per chi vuole attaccarlo.
Cosa chiedere. "Cosa vede un utente quando c'è un errore? Dove vengono registrati i dettagli e chi può leggerli?"
7. Scorciatoie lasciate in produzione
Cos'è. Per provare, l'assistente inserisce accessi di prova ("admin / admin"), dati d'esempio, controlli disattivati ("per ora lascia passare tutti"), commenti "da togliere prima di andare online". Nessuno li toglie.
Come si manifesta. Un account di prova con privilegi massimi e una password prevedibile, rimasto attivo da mesi.
Cosa chiedere. "Ci sono account o dati di prova? Ci sono parti disattivate per comodità? Chi ha controllato prima del rilascio?"
8. Nessun limite agli abusi
Cos'è. Un servizio esposto su internet va protetto dall'uso eccessivo: tentativi ripetuti di accesso, richieste a raffica, invii di massa. Il codice generato raramente lo prevede.
Come si manifesta. Un modulo di contatto usato per inviare migliaia di email; un login attaccato con tentativi di password automatici; un'app che chiama un servizio di IA a pagamento e viene "svuotata" da richieste esterne, con costi che si scoprono sulla fattura.
Cosa chiedere. "Cosa succede se qualcuno prova mille password o invia diecimila richieste in un minuto? Ci sono limiti e avvisi?"
I rischi in una tabella, per chi decide
| Rischio | Cosa vedi (o non vedi) | Domanda chiave |
|---|---|---|
| Segreti nel codice | Nulla, finché non vengono usati da altri | "Dove sono le password?" |
| Accessi difettosi | Un utente vede dati altrui | "Qualcuno ha provato a cambiare un numero nell'indirizzo?" |
| Dati non controllati | Comportamenti strani con testi particolari | "Chi ha fatto i test di base?" |
| Dati personali | Nessuna procedura né registro | "Cosa facciamo in 72 ore?" |
| Librerie | Componenti sconosciuti o vecchi | "Mi dai l'elenco?" |
| Errori troppo parlanti | Messaggi tecnici a schermo | "Cosa vede l'utente?" |
| Scorciatoie | Account o dati di prova attivi | "Cosa è stato tolto prima del rilascio?" |
| Nessun limite | Costi o email anomali | "Cosa succede con mille richieste?" |
Il metodo in sette passi
Un professionista che verifica un'applicazione generata con l'IA segue di solito una sequenza. Conoscerla ti aiuta a capire cosa stai comprando quando chiedi una verifica, e a riconoscere un lavoro serio da uno di facciata.
- Inventario. Cosa esiste, dove gira, quali dati tratta, chi vi accede. Spesso la sorpresa è scoprire più strumenti e più copie di quanti si credesse: è il segnale di un'iniziativa nata fuori controllo.
- Ricerca dei segreti. Si cercano password e chiavi nel codice e nello storico delle modifiche, perché una chiave cancellata oggi può essere ancora leggibile in una versione precedente. Quelle trovate vanno considerate compromesse e cambiate.
- Verifica dei componenti. Si elencano le librerie esterne, si controlla che esistano, siano diffuse, aggiornate e senza falle note.
- Scansione automatica. Strumenti che analizzano il codice cercando difetti noti. Trovano tanto, ma non tutto: sono un filtro, non un giudizio.
- Prove sugli accessi, a mano. Si creano più utenti con ruoli diversi e si prova sistematicamente a vedere ciò che non si dovrebbe. È un lavoro manuale, perché gli strumenti automatici capiscono male le regole di un'azienda.
- Revisione umana delle parti critiche. Qualcuno legge riga per riga i percorsi che contano: accesso, pagamenti, dati personali, caricamento di file. È il passaggio più costoso e più efficace.
- Prova d'attacco prima del rilascio. Un professionista che non ha scritto il codice prova a violarlo, come farebbe un malintenzionato.
Per un'app piccola non serve sempre arrivare al passo sette, ma i primi sei sono il minimo se l'app tratta dati di terzi.
Cosa puoi controllare già oggi, senza essere tecnico
Alcune verifiche sono alla portata di chiunque e danno un'idea rapida dello stato delle cose. Falle su una copia di prova o con l'accordo di chi gestisce l'app.
- Elenco di chi ha accesso, e se ci sono persone che non lavorano più in azienda.
- Due utenti di prova con ruoli diversi: accedi con l'uno e controlla che non veda ciò che spetta all'altro.
- Il lucchetto nel browser: l'indirizzo comincia con "https"? Senza, i dati viaggiano in chiaro.
- Un errore provocato di proposito (per esempio una data impossibile): il messaggio è comprensibile e non rivela dettagli tecnici?
- Dove sono i dati: sul computer di una persona, su un servizio in abbonamento, su un server dell'azienda? Chi lo sa?
- L'ultima copia di sicurezza: esiste? Qualcuno ha mai provato a ripristinarla? Una copia mai provata non è una copia.
- Quanto costa: la fattura dei servizi di IA o di hosting è in linea con l'uso previsto?
Se anche solo due di queste verifiche danno risposte incerte, è il momento di una verifica professionale.
Correggere o rifare?
Dopo la verifica arriva la decisione. Non c'è una regola unica, ma alcuni criteri aiutano.
| Situazione | Strada più sensata |
|---|---|
| Pochi difetti, struttura ordinata, codice leggibile | Correggere e proseguire |
| Difetti diffusi ma struttura coerente | Correggere per priorità, con un piano a tappe |
| Struttura caotica, nessuna logica d'insieme, ogni modifica rompe qualcosa | Rifare, usando l'app come specifica |
| Dati sensibili esposti da tempo | Contenere subito (cambiare accessi e chiavi, limitare l'uso), poi decidere con calma |
| L'app serve davvero e l'azienda ci lavora ogni giorno | Mettere in sicurezza subito e pianificare una versione ben progettata |
Una cosa che spesso sorprende: anche quando si rifà, il lavoro fatto non è perso. L'app generata con l'IA è una specifica concreta di cosa serve agli utenti, e fa risparmiare buona parte dell'analisi. È la funzione di un buon prototipo, come descritto in Quanto costa un MVP.
Quanto costa una verifica
Con l'ipotesi, già usata in altre guide, di circa 450 euro a giornata di lavoro: una verifica di sicurezza di un'applicazione piccola (alcune decine di schermate, un solo ruolo di amministrazione, pochi dati sensibili) richiede in genere da 4 a 10 giornate, cioè circa 1.800–4.500 euro. Per un'applicazione media, con più ruoli, integrazioni e dati personali, il valore sale e si calcola caso per caso. Sono ordini di grandezza costruiti su ipotesi, non preventivi. A questo si aggiungono le correzioni, che dipendono da quante falle emergono.
Il confronto utile non è con zero, ma con il costo di una violazione: tempo, notifiche, assistenza legale, perdita di fiducia dei clienti. Per approfondire come si compone un costo di sviluppo e perché la sicurezza ne fa parte, leggi Quanto costa sviluppare un gestionale su misura.
Cinque pratiche per non ritrovarsi nella stessa situazione
- Distingui prototipo e sistema. Dai un nome diverso e fissa una soglia: quando entrano dati di terzi, o più di un certo numero di utenti, l'app passa a un percorso con progettazione e verifica.
- Nomina un responsabile. Ogni strumento usato in azienda ha qualcuno che risponde di dove sono i dati, chi accede e chi lo aggiorna.
- Non dare a un assistente di IA dati reali o segreti. Password, chiavi, dati di clienti non vanno incollati in una conversazione, a meno che le condizioni d'uso siano state valutate.
- Fai rileggere ciò che finisce in produzione. Una persona competente, diversa da chi ha generato il codice, legge le parti critiche prima del rilascio.
- Tieni un elenco degli strumenti. Sapere cosa c'è è la condizione per proteggerlo.
Dove servono ancora le persone
Si può chiedere a un assistente di IA di "cercare falle di sicurezza" in un'app: è un uso sensato e può far emergere problemi. Resta però un aiuto, non una garanzia, per tre ragioni.
Non conosce le regole della tua azienda. Può dire che un campo non è controllato; non sa che quel dato è riservato e che solo l'ufficio paghe deve vederlo.
Può non vedere ciò che manca. È bravo a commentare il codice che c'è, meno a accorgersi del controllo che nessuno ha scritto.
Non risponde di nulla. Se la verifica sbaglia, nessuno ne risponde a te, ai tuoi clienti o all'autorità.
Per questo la verifica richiede persone: un professionista che conosca la sicurezza delle applicazioni, il contesto del progetto e si assuma la responsabilità del giudizio. Come descritto in I ruoli di un progetto software, è la funzione del collaudo e della sicurezza, tra le prime a mancare nei progetti nati senza regia. E, in generale, vale quanto spiegato in L'intelligenza artificiale non scrive il software al posto tuo: l'IA accelera chi sa, non sostituisce chi manca.
Se hai già un'app in uso: un piano in quattro settimane
Settimana 1: contenere. Elenca chi ha accesso e togli quello non necessario. Cambia password e chiavi che potrebbero essere state esposte. Verifica che esista una copia di sicurezza dei dati. Valuta se limitare temporaneamente l'uso a chi serve davvero.
Settimana 2: capire. Fai l'inventario (cosa c'è, dove, quali dati). Individua se ci sono dati personali e di che tipo. Raccogli l'elenco dei componenti esterni.
Settimana 3: verificare. Affida la verifica a un professionista, con l'ambito concordato (i primi sei passi del metodo sono il minimo se ci sono dati di terzi).
Settimana 4: decidere. Con il risultato in mano, scegli: correggere, rifare, spegnere. Programma le azioni e assegna un responsabile.
Per chiedere un'offerta in modo che sia confrontabile, usa il modello in Come scrivere una richiesta di progetto efficace, indicando che si tratta di una verifica di un'app esistente e di quali dati tratta. Per scegliere chi la fa, la checklist per valutare un freelancer vale anche in questo caso: chiedi esperienza specifica di sicurezza e un esempio di relazione di verifica anonimizzata.
Domande frequenti
Il codice scritto da una persona è più sicuro di quello scritto dall'IA? Non automaticamente. Anche gli sviluppatori sbagliano. La differenza sta nel processo: un professionista usa abitudini, controlli, revisioni e strumenti che il vibe coding salta. Un buon sviluppatore che usa l'IA e rilegge ciò che produce ottiene i vantaggi di velocità senza perdere il controllo.
Posso usare l'IA per costruire software in azienda? Sì, con regole: usarla come strumento di chi sa, non come sostituto di chi manca; rilettura umana di ciò che va in produzione; nessun dato riservato nelle conversazioni senza averne valutato le condizioni; un responsabile per ogni strumento.
L'app è interna, non su internet: devo preoccuparmi? Meno, ma non è zero. Chi ha accesso alla rete interna può essere un dipendente scontento, un computer infetto, un ospite. E se ci sono dati di clienti o dipendenti, gli obblighi di protezione valgono comunque.
Quanto tempo ci vuole per una verifica? Per un'app piccola, da pochi giorni a un paio di settimane, includendo la restituzione dei risultati. Dipende da quanto il codice è leggibile e da quanti problemi emergono.
È obbligatorio notificare una violazione al Garante? Di regola sì, entro 72 ore, salvo che sia improbabile un rischio per le persone. Le valutazioni caso per caso spettano a chi ti assiste sul piano legale e al responsabile della protezione dei dati. Le informazioni ufficiali sono sul sito del Garante per la protezione dei dati personali.
Dove trovo un professionista per verificare o rifare l'app? Per le applicazioni sullo stack Microsoft, su LancerJob trovi sviluppatori freelance specializzati in .NET, con profili che indicano stack ed esperienza. Se il tuo caso richiede un'esperienza specifica di sicurezza, scrivilo nella richiesta di progetto.
In sintesi
- Il vibe coding (descrivere a un'IA ciò che si vuole e accettare il codice senza leggerlo) è ottimo per prototipi ed esperimenti; il problema nasce quando diventa, per inerzia, uno strumento di lavoro con dati reali.
- L'IA produce codice che funziona, non codice sicuro per impostazione predefinita: in uno studio Veracode del 2025, circa il 45% dei compiti ha prodotto codice con una vulnerabilità.
- Gli otto rischi più frequenti sono: segreti nel codice, accessi difettosi, dati non controllati, dati personali senza procedure, librerie inventate o vecchie, errori troppo parlanti, scorciatoie lasciate in produzione, assenza di limiti agli abusi.
- Per una violazione di dati personali, il GDPR prevede di regola la notifica al Garante entro 72 ore: serve una procedura prima che serva.
- La verifica professionale segue sette passi, dall'inventario alla prova d'attacco; per un'app piccola si ordina intorno a 1.800–4.500 euro con le ipotesi dichiarate.
- Anche quando si rifà, l'app generata resta una specifica utile e fa risparmiare analisi.
- La sicurezza richiede persone che conoscano il contesto e si assumano la responsabilità del giudizio: l'IA aiuta, ma non risponde di nulla.