Vulnerabilità nascoste nel codice AI: cosa cercare

Il codice generato con assistenti AI funziona quasi sempre alla prima esecuzione. Ma "funziona" e "è sicuro" sono due livelli diversi. Le vulnerabilità più comuni nel codice AI-generated sono note, ricorrenti, e spesso invisibili a chi non sa dove guardare.

In questa guida vediamo cosa cercare in pratica: i pattern di vulnerabilità che vediamo ricorrere progetto dopo progetto, con esempi concreti e indicazioni su come riconoscerli senza dover essere esperti di security.

1. Validazione input mancante o insufficiente

Il pattern più ricorrente. L'assistente AI scrive codice che riceve input dall'utente e lo passa direttamente a query database, comandi shell o output HTML. Senza validazione esplicita.

Cosa cercare nel codice:

• Endpoint che accettano request.body e lo usano senza controlli
• Query SQL costruite con concatenazione di stringhe invece di parametrizzate
• Output HTML che include direttamente input utente senza encoding
• File path costruiti da input utente

Esempi di rischio reale: SQL injection (rubare l'intero database), command injection (eseguire codice arbitrario sul server), path traversal (leggere file di sistema), XSS (eseguire script nel browser di altri utenti).

2. Gestione credenziali debole

Le password sono il punto più sensibile di un'app. L'AI spesso usa pattern obsoleti: hash MD5 o SHA1 (rotti da anni), password salt mancante, credenziali in plain text in fase di registrazione.

Cosa cercare:

• Funzioni di hashing che usano md5() o sha1() per le password
• Database in cui le password sono leggibili
• API token salvati in file di configurazione versionati su git
• Sessioni che non scadono mai

Standard accettabile oggi: hashing con algoritmo dedicato a costo regolabile, salt per utente, sessioni con scadenza, token con rotation periodica.

3. Dipendenze con CVE note

Ogni libreria di terze parti è un potenziale punto di accesso. Gli LLM tendono a usare le librerie più popolari nei loro training data, che spesso non sono le più aggiornate.

Cosa fare:

• Ogni package manager ha un comando di audit nativo (npm audit, pip-audit, bundle audit, ecc.)
• Esegui l'audit e leggi le segnalazioni: ignorare "low severity", correggere "medium" e "high", risolvere immediatamente "critical"
• Verifica che le dipendenze siano ancora mantenute (ultimo commit recente)
• Diffida di pacchetti con pochi maintainer e basso numero di download

4. Stack trace e dati esposti negli errori

Quando qualcosa va storto in produzione, l'errore deve dire all'utente "qualcosa è andato storto, riprova" — non rivelare la struttura del codice.

Cosa cercare:

• Pagine di errore che mostrano stack trace completi
• Risposte API che rivelano nome del database, query SQL, path dei file
• Log che includono header HTTP, password, token in chiaro
• Variabili d'ambiente esposte in messaggi di errore

Configurazione corretta: errori dettagliati nei log interni, errori generici per l'utente finale.

5. Autorizzazione mancante

L'AI implementa l'autenticazione (login funzionante) ma spesso dimentica l'autorizzazione (chi può fare cosa). Risultato: un utente loggato accede a dati di altri utenti modificando un ID nell'URL.

Cosa cercare:

• Endpoint che ritornano dati utente senza verificare che l'utente loggato sia il proprietario
• Pannelli admin accessibili senza ruolo verificato
• API che permettono di modificare risorse altrui passando un ID diverso
• Mancanza di middleware che valida i permessi

Questo è uno dei pattern più costosi quando viene sfruttato: una vulnerabilità di authorization in un'app con 10.000 utenti significa potenziale data breach completo.

6. Configurazione di sicurezza assente

I siti moderni dovrebbero rispondere con header HTTP che proteggono contro classi intere di attacchi. L'AI raramente li configura proattivamente.

Header minimi che devono essere presenti:

• Strict-Transport-Security (forza HTTPS)
• Content-Security-Policy (limita risorse caricabili)
• X-Content-Type-Options: nosniff
• X-Frame-Options (anti-clickjacking)
• Referrer-Policy

Esistono strumenti pubblici gratuiti che valutano questi header e danno un voto da A+ a F. Sotto B = problema da risolvere.

Tabella riassuntiva

Come procediamo noi negli audit

Quando ci chiamano per un audit codice AI, non improvvisiamo. Seguiamo una sequenza precisa:

1. Scan automatico delle dipendenze (CVE database)
2. Analisi statica del codice alla ricerca di pattern noti
3. Verifica manuale dei punti critici (auth, input validation, query database)
4. Test funzionale delle vulnerabilità più probabili
5. Audit configurazione (header HTTP, secrets management, logging)
6. Report con prioritizzazione: cosa fixare subito, cosa entro 30 giorni, cosa nel medio termine

Tutto in 5-7 giorni lavorativi per un'app di media complessità.

Conclusione

Le vulnerabilità nel codice AI non sono un fenomeno nuovo: sono gli stessi errori che si fanno da 20 anni nello sviluppo software, riprodotti più velocemente perché l'AI li produce in batch senza il filtro dell'esperienza.

La buona notizia: sono tutti correggibili, e la maggior parte si trova con strumenti che esistono e che usiamo da decenni. La difficoltà non è tecnica, è metodologica: fare i controlli prima di esporre l'app al mondo, non dopo che qualcuno trova il problema per noi.

Se la tua app gestisce dati di utenti reali, non c'è scorciatoia. Vale la pena investire in una revisione professionale prima del go-live.