Quanto sono comuni le vulnerabilità di sicurezza nel codice generato dall'IA?

Gli studi sul codice generato dagli LLM mostrano che, sebbene i modelli riescano a compilare codice funzionante in circa il 90% dei casi, circa il 45% di quel codice contiene almeno una vulnerabilità della OWASP Top 10, come un controllo di login aggirabile o una falla di injection.

Perché i generatori di app IA saltano le buone pratiche di sicurezza?

I modelli di IA sono ottimizzati per produrre una demo visivamente funzionante il più rapidamente possibile. Il lavoro di sicurezza, come la validazione lato server, i permessi OAuth limitati e le regole di accesso a livello di riga, non produce alcun progresso visibile in un prompt, quindi è la prima cosa a essere saltata, a meno che tu non la richieda esplicitamente e sappia cosa controllare.

Posso fidarmi di un generatore di app IA per gestire l'autenticazione in modo sicuro?

Solo se l'autenticazione è integrata nella piattaforma invece di essere generata per ogni progetto. Piattaforme create appositamente, come Softr, offrono login, reimpostazione della password, OTP e permessi basati sui ruoli come infrastruttura già pronta, quindi non c'è codice di autenticazione personalizzato che l'IA possa sbagliare.

Che cos'è l'autenticazione lato client e perché è pericolosa?

L'autenticazione lato client significa che i controlli di accesso vengono eseguiti nel browser invece che sul server. Poiché il codice del browser è completamente visibile e modificabile dall'utente, chiunque può aprire gli strumenti per sviluppatori, disattivare il controllo e raggiungere una pagina o un'azione a cui non dovrebbe avere accesso.

I rischi di sicurezza nascosti nelle app generate dall'IA

Un’app vibe-coded può funzionare perfettamente davanti ai tuoi occhi ed essere comunque completamente aperta sotto la superficie. Questa è la parte scomoda della generazione di app tramite IA: la demo funziona, il cliente è colpito, e niente di tutto ciò ti dice se la schermata di login può essere aggirata o se il database è esposto a chiunque ispezioni una richiesta di rete.

I modelli di IA sono addestrati a produrre qualcosa che sembri finito. Non sono addestrati a chiedersi «chi altro potrebbe raggiungere questo endpoint». È in questo divario che si annida la maggior parte del rischio reale nel software generato dall’IA, e raramente emerge prima che qualcuno vada a cercarlo.

I numeri sono peggiori di quanto la maggior parte dei creatori pensi

Ricerche indipendenti sul codice generato dagli LLM lo confermano con un dato preciso e scomodo: i modelli compilano con successo codice funzionante in circa il 90% dei casi, ma circa il 45% di quel codice presenta almeno una vulnerabilità della OWASP Top 10, cose come controlli di login aggirabili o falle di injection che permettono a un attaccante di manipolare una query.

Non è un caso raro. Significa che quasi metà di ciò che uno strumento come Lovable, Bolt o Base44 genera per te da un dato prompt presenta, fin dall’inizio, una debolezza reale e sfruttabile. L’app continua a «funzionare» sotto ogni aspetto visibile. La vulnerabilità semplicemente non si manifesta finché un utente (o un attaccante) non la trova.

Da dove viene davvero il rischio

I difetti di sicurezza nelle app generate dall’IA tendono a raggrupparsi attorno ad alcuni schemi ricorrenti:

Controlli di autenticazione lato client. L’IA implementa «questo utente può vedere questa pagina» nel browser invece che sul server. Poiché il codice del browser è completamente visibile e modificabile, chiunque può aprire gli strumenti per sviluppatori, ribaltare il controllo ed entrare.
Segreti scritti direttamente nel codice. I creatori non tecnici che fanno test in locale spesso non sanno gestire correttamente i file .env, così le chiavi API e le stringhe di connessione al database vengono digitate direttamente nel codice. Quei file finiscono poi su un repository GitHub pubblico senza che nessuno se ne accorga.
Regole del database troppo permissive. Per far funzionare rapidamente un prompt, l’IA configura l’accesso al database in modo ampio invece che ristretto. Se un’altra parte dell’app viene compromessa, quella configurazione completamente aperta trasforma un piccolo bug in una fuga di dati totale.
Connessioni OAuth con permessi eccessivi. Configurare un’integrazione come Google Calendar o Slack richiede di impostare gli scope OAuth a mano. Chiedere troppo accesso crea una responsabilità; dimenticare uno scope rompe l’integrazione in silenzio. In entrambi i casi, chi costruisce l’app sta prendendo una decisione di sicurezza di cui di solito non si rende nemmeno conto.

Niente di tutto questo emerge in una demo. Emerge in un audit di sicurezza, nella console del browser di un utente curioso, o in una notifica di violazione dei dati mesi dopo.

Perché «funziona» è il test sbagliato

La trappola è che i generatori di app IA premiano la velocità di rilascio, e i cicli di feedback rapidi ti abituano a testare solo il percorso ideale. Attraversi il flusso di registrazione, la dashboard si carica, il modulo viene inviato, tutto sembra a posto. Niente di tutto ciò ti dice se l’azione CRUD dietro quel modulo verifica chi sta facendo la richiesta.

Testare davvero la sicurezza significa porsi domande diverse:

Un utente disconnesso può raggiungere direttamente questo URL?
L’utente A può vedere o modificare i record dell’utente B cambiando un ID nella barra degli indirizzi?
I controlli sui ruoli vengono applicati sul server, oppure sono solo nascosti nell’interfaccia?
Le integrazioni collegate via OAuth richiedono solo gli scope che utilizzano davvero?

La maggior parte dei creatori non tecnici non sa di dover porre queste domande, e la maggior parte degli assistenti di codice IA non le solleva spontaneamente a meno che tu non dica esplicitamente «controlla se ci sono problemi di sicurezza»; e anche in quel caso, la correzione è solo un’altra patch generata, non una garanzia strutturale.

L’alternativa: un’infrastruttura che non devi controllare tu

Questo è il vero argomento a favore della costruzione di app aziendali su una piattaforma con la sicurezza integrata fin dalle fondamenta, invece che generata a ogni progetto. Softr è un buon esempio dell’approccio opposto: autenticazione, permessi per ruolo e regole di accesso ai dati sono funzionalità native della piattaforma, non codice che l’IA riscrive per ogni app.

In concreto, questo significa:

CRUD lato server per impostazione predefinita. Le azioni di lettura/scrittura sul database vengono eseguite sui server di Softr, non nel browser, quindi non esiste, a monte, alcun controllo lato client da aggirare.
Permessi per ruolo visuali invece di RLS scritto a mano. I gruppi di utenti e le restrizioni sui dati controllano chi vede e modifica quali record, configurati visivamente e verificati tramite impersonificazione in anteprima, invece di essere sepolti in codice di policy del database facile da configurare male.
Connettori OAuth pre-verificati. Le integrazioni con strumenti come Google Calendar, HubSpot e Stripe usano le applicazioni sviluppatore già approvate di Softr, quindi chi costruisce l’app non tocca mai gli scope OAuth grezzi né conserva da solo le credenziali di terze parti.
Flussi di autenticazione già pronti all’uso. Login, reimpostazione della password, OTP e registrazione limitata per dominio sono già integrati, quindi non c’è logica di autenticazione personalizzata che un’IA possa implementare male in modo sottile.

Questo non significa che gli strumenti generati dall’IA siano inadatti a tutto. Per un progetto personale, un prototipo interno che nessuno fuori dal tuo team toccherà, o una landing page statica, il profilo di rischio è basso e il vibe coding è davvero la strada più veloce. Il calcolo cambia nel momento in cui entrano in gioco utenti reali, dati reali dei clienti o login esterni.

Cosa controllare prima di lanciare

Se comunque stai costruendo con uno strumento IA che genera codice, una lista breve è meglio di niente:

Cerca nel codice (grep) chiavi API e stringhe di connessione scritte direttamente prima di ogni commit.
Verifica che i controlli di accesso siano duplicati anche sul server, e non solo nascosti nel frontend.
Rivedi gli scope OAuth concessi a ogni integrazione collegata ed elimina quelli non usati.
Chiedi a una seconda persona, idealmente tecnica, di provare ad accedere ai dati di un altro utente indovinando o modificando un ID nell’URL.

Questa lista non renderà il codice generato sicuro quanto un’infrastruttura mai generata, ma intercetta i difetti che ricorrono più spesso. Per un portale, un CRM o uno strumento interno in cui persone reali accederanno con dati reali, la soluzione più duratura è scegliere una base dove il lavoro di sicurezza è già stato fatto, così da non giocarsela a ogni prompt.