La statistica circola in due metà, e le persone citano sistematicamente quella rassicurante. Gli LLM producono codice che compila con successo circa il 90% delle volte. L’altra metà: circa il 45% di quel codice contiene vulnerabilità di classe OWASP Top 10, l’elenco standard del settore delle falle di sicurezza più comuni e gravi, come controlli di login bypassabili e bug di injection. Vale la pena essere precisi su cosa significhi e cosa non significhi, prima che ciò causi panico o venga ignorato.
Cosa NON significa questo numero
Non è un’affermazione secondo cui il 45% delle app create con l’IA venga hackerata, né che il codice generato sia unicamente pessimo; anche gli sviluppatori umani scrivono codice vulnerabile, ed è per questo che esiste la lista OWASP. E non è un argomento a sostegno dell’inutilità degli strumenti di coding AI, poiché uno sviluppatore che revisiona l’output intercetta gran parte di questi problemi durante il normale flusso di lavoro.
Ecco cosa significa: lancia una moneta per ogni generazione, e quelle sono approssimativamente le probabilità che il codice contenga una falla dal catalogo delle vulnerabilità più note del settore, pur compilando e funzionando perfettamente in demo. La falla non ha alcun impatto sul comportamento visibile. È qui che sta la trappola.
Perché un codice che funziona non è necessariamente codice sicuro
I modelli AI ottimizzano per un rapido successo visivo, perché è ciò che il prompt ha richiesto e ciò che lo sviluppatore può verificare guardando. La sicurezza è precisamente la proprietà che non puoi vedere dalla finestra di anteprima, e le modalità di fallimento documentate seguono questo schema. Il controllo degli accessi viene implementato nel browser invece che sul server, quindi un utente può bypassare il controllo modificando il codice sulla propria macchina; l’app appare identica in entrambi i casi. I permessi del database vengono configurati in modo troppo ampio affinché tutto funzioni al primo colpo, lasciando i dati esposti se qualsiasi altra parte dell’app viene compromessa. I segreti vengono inseriti hardcoded nei file perché la gestione delle variabili d’ambiente è esattamente il tipo di compito invisibile che sia i modelli che i principianti saltano, e tali credenziali finiscono poi su repository GitHub pubblici. E i flussi di utilità che hanno un peso reale in termini di sicurezza (recupero password, verifica OTP, gestione delle sessioni) semplicemente non vengono costruiti, perché nessuno li mostra in demo.
La posizione di fiducia dello sviluppatore peggiora le cose. Un operatore non tecnico non può leggere il codice generato per verificare nulla di tutto ciò, e i test manuali percorrono il “percorso ideale”, non il bypass. L’app che “funziona perfettamente” e l’app che disperde i record di ogni cliente possono essere la stessa app.
Cosa controllare prima che gli utenti reali effettuino l’accesso
Un audit minimo, in termini semplici. Primo, applicazione lato server: conferma che ciò che un utente può vedere sia deciso sul server o nelle regole del database, e non nascondendo semplicemente dei pulsanti nell’interfaccia utente. Secondo, postura del database: le regole dovrebbero negare l’accesso di default e concederlo in modo restrittivo; negli strumenti basati su Supabase come Lovable, ciò significa leggere effettivamente le policy RLS, non fidarsi del fatto che il prompt le abbia generate. Terzo, igiene dei segreti: cerca nel repository chiavi hardcoded e stringhe di connessione, specialmente se il progetto è stato sincronizzato con un repository pubblico. Quarto, i flussi dimenticati: reset password, scadenza sessione e restrizioni all’iscrizione devono esistere e funzionare. Quinto, il test del secondo utente: crea due account e prova a raggiungere i dati di un utente dalla sessione dell’altro, anche modificando direttamente gli URL. Nulla di tutto questo è esoterico; è esattamente ciò che la generazione salta.
E nota la clausola di manutenzione: questo non è un controllo una tantum. Ogni rigenerazione è un nuovo lancio degli stessi dadi, quindi il loop di correzione su una funzionalità legata all’autenticazione significa dover rirverificare il livello che avevi già verificato, pagando per il round che effettua tale rirverifica. Questo onere di rirverifica è un volto del problema del Giorno Due: l’audit che esegui oggi è l’audit che dovrai rieseguire dopo la prossima modifica.
Il bivio dell’onestà
Quell lista di audit rappresenta il costo reale di quella percentuale del 45%, e ci sono esattamente due modi per affrontarlo. Assumersi la responsabilità della revisione: tu o uno sviluppatore di fiducia leggete il codice generato a ogni iterazione, trattando l’IA come un junior veloce di cui va sempre verificato il lavoro sulla sicurezza. Questa è un’opzione percorribile per gli sviluppatori, ma un’illusione per chiunque altro. Oppure eliminare l’intermediario: per le applicazioni business come portali e strumenti interni, costruite su una piattaforma come Softr, dove l’autenticazione, i permessi e le regole di accesso ai dati sono configurati visivamente a livello di infrastruttura e non sono codice generato per singolo progetto; in questo modo, la “lotteria del 45%” non colpirà mai il livello più critico. Quella che non è un’opzione è la popolare terza via: generare il codice, dare un’occhiata veloce alla demo e pubblicare. Se questa statistica esiste, è proprio perché è quello che fa la maggior parte delle persone.