Codice generato da AI: 12 controlli da fare prima del go-live

Hai sviluppato un'app con un assistente AI. Funziona sul tuo computer. La schermata è bella, le pagine si caricano, l'utente di test riesce a registrarsi e a usarla. Sei pronto per lanciarla?

Probabilmente no.

Quello che vedi sul tuo dispositivo è il 15% di quello che conta. Il restante 85% — sicurezza, conformità, performance, scalabilità, costi — non è visibile finché qualcosa non si rompe. E quando si rompe, è troppo tardi.

In questa guida ti diamo i 12 controlli concreti da fare prima di esporre la tua app vibe-coded al pubblico. Per ognuno: cosa verificare, come farlo, perché conta.

1. Password e credenziali

Cosa controllare: come vengono salvate le password degli utenti.

Come: apri il database di test e cerca un utente. Se vedi la password in chiaro, c'è un problema. Anche se vedi un hash che inizia con md5( o sha1(, c'è un problema. Le password devono essere salvate con un algoritmo dedicato e con un fattore di costo regolabile.

Perché conta: in caso di breach (accesso non autorizzato al database), gli utenti subiscono il furto delle credenziali, che spesso sono riutilizzate su altri servizi. La responsabilità è di chi ha lasciato le password vulnerabili.

2. Validazione di tutti gli input utente

Cosa controllare: ogni campo in cui l'utente può scrivere qualcosa va trattato come potenzialmente ostile.

Come: cerca nel codice ogni request.body, req.params, query.X. Verifica che ci sia una libreria di validazione (schema validator) che controlla tipo, lunghezza, formato. Per i campi che finiscono in query database, in comandi shell o in HTML renderizzato, serve un'attenzione specifica.

Perché conta: SQL injection, command injection e XSS sono attacchi vecchi di 25 anni che continuano a funzionare quando l'input non è validato. Sono anche tra i primi che i bot automatici tentano sui nuovi domini.

3. Rate limiting e protezione brute-force

Cosa controllare: quanto è facile per un attaccante provare 10.000 password al secondo sul tuo login.

Come: prova a fare 50 login falliti consecutivi sullo stesso account. Se non vieni bloccato, manca rate limiting. Per i servizi pubblici di autenticazione, il blocco temporaneo dopo N tentativi è un minimo.

Perché conta: senza rate limiting, qualsiasi account può essere attaccato in massa. Con account legati a piani a pagamento, può portare a utilizzo improprio o frodi.

4. Privacy policy e cookie banner

Cosa controllare: la privacy policy esiste, è linkata in homepage, descrive davvero quello che il sito fa con i dati. Il cookie banner blocca i tracker prima del consenso esplicito.

Come: apri il sito da nuova sessione. Verifica che prima di accettare il banner non parta nessuna chiamata a domini di terzi (analytics, ads, mappe). La privacy policy deve essere coerente con quello che il sito raccoglie davvero.

Perché conta: il GDPR si applica sempre, e i Garanti europei sanzionano regolarmente siti italiani che usano un cookie banner non conforme. Le sanzioni partono da poche migliaia di euro per le PMI e crescono velocemente.

5. Crittografia dei dati a riposo

Cosa controllare: i dati sensibili nel database sono crittografati o sono in chiaro.

Come: dipende dal tipo di dato. Numeri di telefono, indirizzi, dati di pagamento, testi di conversazioni private vanno protetti almeno con crittografia a livello di colonna (per i campi più sensibili) e/o crittografia a livello di disco.

Perché conta: se il database viene esfiltrato, dati in chiaro = utenti compromessi direttamente. Dati cifrati = tempo per reagire e mitigare.

6. Dipendenze e CVE noti

Cosa controllare: ogni libreria di terze parti usata dalla tua app è aggiornata e libera da vulnerabilità note.

Come: i package manager hanno comandi di audit incorporati che mostrano le vulnerabilità note delle dipendenze attuali. Il risultato deve essere "0 vulnerabilità ad alto/critico". Se ce ne sono, vanno aggiornate o sostituite.

Perché conta: una vulnerabilità in una dipendenza è una porta aperta nel tuo software, anche se il codice che hai scritto tu è perfetto. I bot automatici scansionano i siti per identificare versioni vulnerabili note.

7. Configurazione errori e logging

Cosa controllare: cosa vede l'utente quando qualcosa va storto.

Come: forza un errore in un endpoint (passa un parametro nullo dove ne serve uno valido). La risposta deve essere un messaggio generico ("Si è verificato un errore"), non uno stack trace con il path del server, le librerie usate e — peggio — le query SQL.

Perché conta: gli stack trace pubblici sono regali per gli attaccanti: rivelano la tecnologia, la struttura, a volte le credenziali. In produzione vanno solo nei log interni.

8. Test di carico base

Cosa controllare: la tua app regge un picco di utenti simultanei realistico per il tuo caso.

Come: esistono strumenti gratuiti che simulano traffico (es. 100 utenti simultanei per 5 minuti). Se il sito rallenta drammaticamente o crasha, l'infrastruttura non è dimensionata o il codice ha colli di bottiglia.

Perché conta: il giorno del lancio, il giorno di una menzione su un giornale, il giorno di un picco virale: la tua app deve reggere. Un crash sotto carico è il peggior biglietto da visita.

9. Backup e procedura di restore

Cosa controllare: i dati vengono salvati automaticamente in un altro luogo, e sai esattamente come ripristinarli se serve.

Come: imposta backup giornalieri automatici. Almeno una volta — prima del lancio — esegui una procedura di restore completa su un ambiente di test. Solo così sai che il backup è davvero utilizzabile.

Perché conta: il giorno in cui un dipendente cancella per errore una tabella, o un attacco ransomware blocca il database, la differenza tra un'azienda e un'azienda che chiude è il backup testato.

10. Monitoraggio e alert

Cosa controllare: se l'app si rompe, qualcuno se ne accorge prima dell'utente.

Come: configura un sistema di alert per: errori 500 (errori server), tempi di risposta sopra soglia, fallimenti dei job di backup, certificati TLS in scadenza. Anche un alert via email è un punto di partenza.

Perché conta: senza monitoraggio, l'unica fonte di feedback è la lamentela dell'utente. E ogni utente che sperimenta un errore probabilmente non lo segnalerà: cambierà servizio.

11. Costi cloud sotto controllo

Cosa controllare: spesa cloud prevista, alert su soglia, dimensionamento delle risorse.

Come: la maggior parte dei provider cloud permette di impostare un budget mensile con alert automatici. Verifica che le risorse (database, container, storage) siano dimensionate per il traffico atteso, non sovradimensionate per sicurezza.

Perché conta: un'app vibe-coded può facilmente fare 10× le query necessarie per ogni pagina, o tenere container attivi quando potrebbero spegnersi. Sul mese si trasforma in fattura sorprendente.

12. Header di sicurezza HTTP

Cosa controllare: il sito risponde con i giusti header di sicurezza.

Come: esistono strumenti pubblici (security header scanners) che danno un voto da A+ a F. Il minimo accettabile è B. Vanno presenti almeno: HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy.

Perché conta: alcuni di questi header proteggono da attacchi specifici (clickjacking, MIME sniffing, injection di script). Non costano nulla configurarli, e fanno una differenza concreta.

Riassunto in tabella

Totale stimato: 20-35 ore di lavoro per un'app di media complessità, se sai cosa fare. Se non lo sai, raddoppia.

L'errore più costoso che vediamo

Il pattern peggiore non è "fare male i controlli". È non farli affatto e scoprire dopo che mancavano. Quando un sito viola il GDPR, il provvedimento del Garante arriva mesi dopo — e a quel punto recuperare è molto più costoso.

Trattare la pre-launch checklist come parte naturale del progetto, e non come un fastidio da fare "se rimane tempo", è la differenza tra un lancio sereno e una corsa contro il danno.

Conclusione

Sviluppare con l'AI è la novità più importante degli ultimi 10 anni nel software. Permette a chiunque abbia un'idea di portarla in vita. Ma il software che incontra utenti reali è sempre stato — e sarà sempre — un terreno tecnico, dove la qualità dell'esecuzione conta quanto la qualità dell'idea.

I 12 controlli di questa guida non sono un esame: sono il minimo sindacale per non fare danni a sé stessi e ai propri utenti. Se li fai (o li fai fare), parti col piede giusto. Se li salti, prima o poi lo paghi.

La buona notizia è che farli — una volta — è molto meno faticoso di quello che sembra.