La tua app costruita con l'IA è pronta per la produzione?

Cosa produce davvero il "vibe coding"

Chiedi a un assistente IA un flusso di login e ne otterrai uno che effettua l'accesso. Di solito non limiterà i tentativi di login, non applicherà un hashing sicuro delle password con un salting adeguato, non invaliderà le vecchie sessioni, né verificherà che un utente sia autorizzato a vedere proprio il record richiesto e non uno qualsiasi. Chiedi un'API e otterrai un endpoint che restituisce dati, spesso senza controllare chi lo sta chiedendo, se è autorizzato a farlo, o cosa succede quando lo chiedono in mille contemporaneamente. Niente di tutto questo emerge in una demo. Emerge la prima volta che qualcuno lancia uno script contro la tua API, o il giorno in cui un articolo ti porta un picco di traffico.

Le tre modalità di fallimento

Quasi ogni app costruita con l'IA che finisce nei guai fallisce in uno di tre modi. Sicurezza: controlli di autorizzazione che sembrano presenti ma non verificano davvero la proprietà del dato, segreti versionati nel repository o inviati al bundle client, CORS permissivo e nessun rate limiting. Scalabilità: query al database senza indici, senza cache e senza connection pooling, che funzionano bene con dieci righe e crollano con diecimila. Manutenibilità: nessun test, nessun monitoraggio degli errori, nessuna separazione chiara tra i componenti, così ogni nuova funzionalità generata dall'IA rischia concretamente di rompere silenziosamente qualcosa di già esistente. Uno solo di questi problemi è gestibile. Scoprirli tutti e tre insieme, in produzione, durante un lancio, no.

Una checklist di autovalutazione in 10 punti

Puoi individuare buona parte di questi problemi da solo, prima di un audit. Ripassa la tua app e rispondi onestamente:

1. 1.I tuoi endpoint API verificano che l'utente loggato sia il proprietario del record richiesto, non solo che sia presente un token?
2. 2.Le API key e le credenziali del database sono in variabili d'ambiente, non scritte fisse nel codice o versionate nel repository?
3. 3.Un git log del tuo repository troverebbe un segreto che è stato versionato e poi "rimosso"? Rimuoverlo dall'ultimo commit non lo rimuove dalla cronologia.
4. 4.C'è un rate limiting su login, registrazione e su qualsiasi endpoint che invia email o ti costa denaro per chiamata, come API di IA o SMS?
5. 5.Le tue query al database usano indici sulle colonne su cui filtri e ordini, o rallenterebbero linearmente con la crescita delle righe?
6. 6.Se il server si riavvia o una richiesta fallisce a metà, c'è un monitoraggio che te lo segnala, o lo scopriresti dal reclamo di un utente?
7. 7.Esiste un backup testato del database, o la perdita dei dati sarebbe permanente?
8. 8.La configurazione CORS accetta richieste da qualsiasi origine, o solo dai domini che dovrebbero chiamare la tua API?
9. 9.L'input dell'utente viene validato e sanitizzato prima di arrivare al database o di essere mostrato ad altri utenti, o passa direttamente dal corpo della richiesta?
10. 10.Le tue risposte di errore espongono stack trace, percorsi di file interni o errori grezzi del database al client, o vengono sanitizzate prima di arrivare all'utente?

Cosa copre un audit di prontezza per la produzione

Se a diverse di queste domande non hai risposto "sì" con sicurezza, è la condizione normale per un'app costruita per validare un'idea, non per reggere il successo di quell'idea. Un audit di prontezza per la produzione è un'analisi strutturata proprio su questi aspetti: autenticazione e autorizzazione, segreti e configurazione, scalabilità di database e infrastruttura, e qualità del codice, consegnata come lista di priorità da correggere, non come un report che devi tradurre tu in azioni concrete.

FAQ