App generata con AI: 15 controlli di sicurezza prima del go-live

Quando una web app, un MVP SaaS o un tool interno creato con AI sembra funzionare, la pressione naturale è pubblicarlo. Il problema è che “funziona” e “può andare online” sono due condizioni diverse. Prima di collegare dati reali, utenti, pagamenti, API aziendali o sistemi interni, serve una verifica concreta su codice, configurazioni, autorizzazioni e comportamento esposto.

Questa checklist è pensata per team che hanno usato ChatGPT, GitHub Copilot, Cursor, Codex, Claude Code, Lovable, Bolt.new, v0, Replit Agent, Devin, Kiro, Gemini o altri strumenti di AI coding. Prima del go-live conta ciò che è stato costruito, cosa è esposto e quali rischi possono arrivare in produzione insieme alla feature.

Usala prima del go-live, prima di una beta con clienti, prima di importare dati reali o prima di collegare l’app a pagamenti, CRM, database aziendali, cloud storage o API interne.

Il valore della checklist aumenta quando viene applicata su un ambiente reale, non solo sul repository. Molte vulnerabilità non si vedono leggendo una singola funzione: emergono quando codice, ruoli, route, configurazioni cloud, storage, callback e variabili ambiente lavorano insieme. Per questo ogni controllo dovrebbe produrre un’evidenza verificabile — una richiesta HTTP, una configurazione, una policy, un test negativo, uno screenshot di permessi o una decisione di remediation.

Prima di iniziare: definisci il perimetro reale

Una checklist funziona solo se il perimetro è chiaro. Prima dei 15 controlli, raccogli almeno queste informazioni: repository o progetto, URL di staging e produzione, route pubbliche, API, ruoli utente, dati trattati, provider di autenticazione, database, storage, servizi cloud, variabili ambiente, dipendenze aggiunte dall’AI e parti generate o modificate con assistenti o agenti.

Se non riesci a ricostruire questi elementi, il primo rischio è proprio la mancanza di controllo sul go-live. Un’app AI-generated può essere stata costruita rapidamente, ma prima di pubblicarla deve diventare un prodotto verificabile.

Il perimetro deve includere anche ciò che è stato aggiunto per far funzionare rapidamente il prototipo: pacchetti installati, integrazioni temporanee, account di servizio, webhook di test, bucket creati durante lo sviluppo, chiavi condivise in chat, prompt usati per generare codice e parti copiate da esempi. Sono elementi che spesso non compaiono nella user story, ma possono decidere il livello di esposizione reale dell’app.

Cosa diventa pubblico al go-live

Il primo controllo è inventariare ciò che sarà raggiungibile: dominio, sottodomini, API, webhook, callback, storage, preview deployment, pannelli admin, route di debug, file statici e ambienti temporanei. Molti incidenti nascono da ciò che il team non pensava di aver pubblicato.

Controlla che demo, endpoint di test, dati seed, account admin temporanei, pagine diagnostiche e messaggi di errore verbosi non siano raggiungibili. Se usi Vercel, Replit, Lovable, Bolt.new, Firebase, Supabase o cloud simili, verifica anche preview URL, deploy precedenti e domini custom.

Questo inventario va confrontato con l’intenzione di prodotto. Se una route è pubblica solo perché il framework l’ha esposta di default, se un ambiente di preview resta indicizzato, se una funzione serverless accetta chiamate senza autenticazione o se un endpoint admin risponde fuori dalla VPN, la superficie d’attacco è più ampia di quanto previsto. Prima del go-live, ciò che non serve deve sparire; ciò che serve deve avere controllo di accesso, logging e limiti coerenti.

Autenticazione, sessioni e recupero account

L’autenticazione deve essere verificata oltre il login felice. Prova registrazione, login, logout, reset password, inviti, cambio email, cambio password, scadenza sessione e revoca token. Se l’app gestisce dati sensibili, ruoli amministrativi o pagamenti, valuta MFA o controlli equivalenti.

Gli errori più frequenti nelle app generate con AI sono sessioni troppo lunghe, reset password riutilizzabili, token non invalidati dopo cambio password, inviti scaduti ancora validi, controlli solo lato frontend e messaggi di errore che rivelano se un account esiste. Prima di pubblicare, ogni flusso di account deve essere testato con utente valido, utente non valido, token scaduto, link già usato e tentativi ripetuti.

Controlla anche il comportamento tra dispositivi e sessioni parallele. Un cambio password dovrebbe invalidare i token dove necessario, un logout dovrebbe chiudere davvero la sessione, un invito non dovrebbe poter essere usato da un account diverso da quello previsto. Nelle applicazioni B2B, verifica anche cosa succede quando un utente lascia un’organizzazione, cambia ruolo o viene rimosso da un tenant.

Autorizzazioni, BOLA e tenant isolation

Broken access control è uno dei rischi più critici per web app e API. Nelle app create con AI si presenta spesso così: l’utente è autenticato, ma può accedere a oggetti che non gli appartengono cambiando un ID nella richiesta.

Testa manualmente user_id, project_id, tenant_id, organization_id, order_id, document_id e ogni identificativo controllabile dal client. Un utente standard deve provare a leggere, modificare, cancellare o esportare record di altri utenti; un utente di un tenant deve provare ad accedere a risorse di un altro tenant.

Il controllo deve essere server-side. Nascondere un bottone nella UI non protegge l’API: ogni endpoint deve verificare identità, ruolo, ownership e tenant prima di restituire o modificare dati. Le app generate con AI possono introdurre questo problema in modo sottile — una nuova pagina usa un filtro lato client, una funzione di export dimentica il tenant_id, un endpoint di dettaglio controlla solo che l’utente sia loggato, una query usa un ID ricevuto dal browser senza verificare ownership. Il test deve attraversare flussi diversi, non limitarsi alla schermata principale.

API e route non visibili nella UI

Molte app generate con AI hanno route create per debugging, test o comodità che, anche se non compaiono nell’interfaccia, possono restare raggiungibili via browser, curl, proxy o script.

Chiama direttamente tutte le API e prova metodi HTTP diversi, token mancanti, token scaduti, ruoli insufficienti, payload incompleti, parametri manipolati e richieste fuori sequenza. Verifica route admin, endpoint export, upload, import, webhook, callback, health check e funzioni server-side. Se una route non deve esistere in produzione, rimuovila; se deve esistere, proteggila con autenticazione, autorizzazione, rate limit, logging e gestione errori coerente.

Includi nel controllo anche route create da convenzioni del framework: endpoint API generati automaticamente, pagine dinamiche, funzioni serverless, callback OAuth, webhook di pagamento, URL di anteprima e route per cron job. Una UI pulita può nascondere un backend molto più ampio di quanto il team ricordi.

Validazione input, output handling e file upload

Il codice generato dall’AI può gestire correttamente il percorso previsto e ignorare del tutto input malevoli. Verifica form, query string, JSON body, header, filename, path, template, markdown, HTML e valori numerici.

I casi minimi da testare includono SQL injection, NoSQL injection, XSS, path traversal, command injection, SSRF dove pertinente, upload di file attivi, estensioni doppie, MIME type falsificato, file troppo grandi e dati fuori formato. La validazione deve essere lato server, con allowlist dove possibile. Anche l’output va gestito: errori, log, messaggi all’utente, export e rendering HTML non devono esporre stack trace, token, query, path interni o dati di altri utenti.

Per gli upload, verifica tutto il ciclo di vita del file: caricamento, scansione o validazione, salvataggio, download, anteprima, cancellazione e accesso tramite link condiviso. Se l’app genera anteprime, PDF, immagini o documenti, controlla che il contenuto caricato non venga interpretato come codice o riutilizzato in prompt, template o workflow automatici senza sanitizzazione.

Segreti, API key e credenziali

Cerca segreti in codice, file .env, history Git, prompt, chat, log, output di build, artifact, test, README, esempi e configurazioni. Le app AI-generated spesso contengono chiavi inserite “temporaneamente” per far funzionare una demo.

Se una chiave è stata esposta in un repository, prompt, log o artifact, va ruotata: rimuoverla dal file non basta. Usa secret manager o variabili ambiente gestite, separa dev/staging/prod e assegna scope minimi. Attenzione al frontend: una chiave privata non deve finire nel bundle, in una pagina, in una response JSON o in un log client-side.

La verifica deve includere build finale e artifact, non solo sorgenti. Cerca chiavi nel bundle minificato, nelle source map, nei log della pipeline, nei container, nei file di configurazione esportati e negli esempi lasciati nel repository. Se un assistente AI ha suggerito di incollare una chiave per “testare velocemente”, trattala come potenzialmente compromessa finché non è stata ruotata.

Dati personali, dati aziendali e ambienti

Prima del go-live devi sapere quali dati tratti, dove finiscono e chi può leggerli. Dati personali, documenti cliente, log applicativi, payload di webhook, ticket, screenshot, export e backup devono avere una collocazione chiara.

Le demo generate con AI spesso usano dati reali troppo presto. Separare sviluppo, staging e produzione riduce il rischio: usa dati sintetici quando possibile, evita dump reali nei repository e verifica la retention dei log. Se l’app tratta dati personali, controlla base giuridica, informativa, minimizzazione, accesso, cancellazione, conservazione e fornitori coinvolti. Questo non sostituisce una valutazione privacy, ma evita di pubblicare senza sapere dove passano i dati.

Un controllo utile è seguire un singolo dato dall’inserimento alla cancellazione: form, API, database, log, email, notifiche, webhook, analytics, backup ed export. Questo percorso mostra rapidamente se l’app conserva più informazioni del necessario o se dati di produzione finiscono in ambienti di sviluppo, strumenti di supporto, sistemi di tracciamento o prompt usati per debug.

Database, BaaS e regole di sicurezza

Se usi Supabase, Firebase, Replit Database, database SQL gestiti o backend-as-a-service, non basta che l’app legga e scriva correttamente: devi verificare le regole di accesso.

• Per Supabase: controlla Row Level Security, policy per ruolo e tenant, service role key mai nel client, funzioni SQL, storage policies e anon key.
• Per Firebase: controlla Firestore/Realtime Database Rules, Storage Rules, custom claims e default deny.
• Per database SQL: controlla query, filtri user_id/tenant_id, migration, backup e accesso di rete.

Il test più importante resta manuale: due utenti diversi, due tenant diversi, oggetti simili, API dirette e tentativi di leggere o modificare dati non autorizzati. Non dare per scontato che le regole del BaaS siano equivalenti alla logica applicativa: una pagina può mostrare solo i dati corretti, ma una policy permissiva può permettere accesso diretto dal client. Al contrario, una policy troppo rigida può spingere il team a usare service key lato server senza controlli granulari. Prima della pubblicazione serve coerenza tra regole, codice e modello dati.

Storage, bucket e documenti caricati

Upload e storage sono spesso aggiunti in fretta dagli app builder AI. Verifica chi può caricare, leggere, scaricare, cancellare e condividere file, perché un bucket pubblico o un URL prevedibile può esporre documenti aziendali anche se il resto dell’app richiede login.

Controlla separazione tra asset pubblici e file privati, MIME type, dimensione massima, estensioni, path traversal, antivirus o controlli equivalenti quando necessari, expiration dei link, backup e cancellazione. Prova download e delete con utenti diversi: un utente non deve poter scaricare file di un altro cliente solo modificando ID, path o nome file.

Verifica anche i metadati. Nome file originale, autore, dimensione, path, tag, anteprime e testo estratto possono rivelare informazioni sensibili anche quando il file principale sembra protetto. Se i documenti caricati vengono processati da funzioni AI, controlla dove vengono salvati i risultati dell’estrazione e chi può leggerli.

Dipendenze, lockfile e supply chain

Gli strumenti AI aggiungono spesso pacchetti per risolvere errori velocemente. Ogni modifica a package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, lockfile e script install/build/test va revisionata.

Controlla vulnerabilità note, manutenzione del pacchetto, licenza, dipendenze transitive, typosquatting, script postinstall, versioni bloccate e librerie quasi omonime. Se una dipendenza è stata aggiunta solo per far passare un test, chiedi se esiste una soluzione più semplice o già approvata. SCA e dependency review aiutano, ma non sostituiscono la decisione tecnica: quella libreria deve davvero entrare nel prodotto?

Quando l’AI modifica dipendenze, guarda anche cosa viene rimosso. Un upgrade può cambiare middleware di sicurezza, parsing, validazione, gestione cookie o comportamento di default; una libreria sostituita con un’alternativa più semplice può perdere controlli che il team dava per acquisiti. La review deve includere lockfile e diff di configurazione, non solo il codice applicativo.

Cloud, deploy e configurazioni

Il deploy è il punto in cui scorciatoie e default diventano esposizione reale. Verifica CORS, CSP, security headers, callback, redirect, debug mode, error reporting, rate limit, variabili ambiente, IAM, security group, bucket, database pubblici, container, serverless function e IaC.

Una configurazione generata dall’AI può risolvere un errore di build e indebolire la sicurezza allo stesso tempo. CORS *, redirect non allowlistati, debug attivo, errori dettagliati, secret nei log di deploy e permessi cloud troppo ampi sono problemi da bloccare prima della pubblicazione. Se il progetto usa AWS, Google Cloud, Firebase, Supabase, Vercel, Replit o altri ambienti gestiti, controlla anche separazione dev/staging/prod e privilegi dei service account.

Le configurazioni di deploy meritano una prova in ambiente simile alla produzione: verifica header reali, redirect effettivi, comportamento degli errori, asset pubblicati, response delle API, callback consentite e accesso da rete esterna. Un file di configurazione corretto nel repository non garantisce che la piattaforma stia eseguendo l’app con gli stessi valori.

CI/CD, branch protection e artifact

La pipeline deve impedire che codice generato o modificato dall’AI arrivi in produzione senza review. Controlla branch protection, reviewer obbligatori, test minimi, secret scanning, dependency scanning, build artifact, log CI/CD e permessi dei token.

Attenzione alle modifiche che “semplificano” la pipeline: test disabilitati, step di sicurezza rimossi, token con scope più ampio, deploy automatico su branch non protetti, log più verbosi, cache che contiene dati sensibili. Se usi agenti che aprono PR o modificano pipeline, richiedi approvazione umana sulle aree sensibili: auth, API, segreti, dipendenze, IaC, deploy e dati.

Controlla inoltre cosa viene conservato come artifact. Report, build, coverage, log, dump di test, screenshot e pacchetti compressi possono includere dati o configurazioni che non dovrebbero uscire dalla pipeline. Una pipeline veloce ma troppo verbosa può trasformarsi in una seconda superficie di esposizione.

Test negativi e casi di abuso

I test generati dall’AI coprono spesso il percorso felice. Prima del go-live servono test che provano a rompere le regole: utenti senza permesso, tenant diversi, token scaduti, input malevoli, upload non validi, race condition, flussi fuori ordine, pagamenti manipolati, inviti riutilizzati, reset password abusato.

Ogni controllo critico dovrebbe avere almeno un test positivo e uno negativo. Se una feature riguarda dati o ruoli, serve dimostrare non solo che l’utente giusto riesce, ma che l’utente sbagliato non riesce. Il WAPT manuale è utile perché porta un mindset diverso: non chiede se la feature funziona, ma come può essere abusata dall’esterno.

Per ogni flusso importante prepara almeno una domanda di abuso: posso creare qualcosa senza pagare, vedere dati di un altro utente, ripetere un’azione, saltare uno step, forzare uno stato, usare un token vecchio, cambiare prezzo, modificare quantità, aggirare un limite, esportare più dati del previsto? Le risposte a queste domande contano più della copertura percentuale dei test.

Logging, monitoring e audit trail

Log e monitoraggio servono per capire cosa succede dopo il go-live, ma possono diventare un rischio se contengono token, PII, payload sensibili, query, stack trace o dati di altri utenti.

Verifica quali eventi critici vengono registrati: login, reset password, cambio ruolo, azioni admin, export, delete, pagamento, upload, errori, cambi configurativi e accessi anomali. I log devono essere utili per incident response, ma minimizzati e protetti. Se l’app è creata con agenti AI, conserva anche evidenze di cosa è stato generato, quali PR sono state accettate, quali test sono passati e quali remediation sono state fatte: l’audit trail aiuta a ricostruire decisioni e responsabilità.

Il monitoraggio deve essere pronto prima del lancio, non aggiunto dopo il primo incidente. Definisci quali eventi producono alert, chi li riceve, quali soglie indicano abuso e quali azioni sono previste. Per una web app esposta, login falliti, errori 403/401 anomali, spike su endpoint sensibili, upload insoliti, export massivi e reset password ripetuti sono segnali da trattare con attenzione.

Decisione di remediation prima del go-live

La checklist non serve se alla fine non produce una decisione. Ogni finding deve avere uno stato: correggere prima del go-live, accettare temporaneamente con motivazione, monitorare, oppure bloccare la pubblicazione.

Blocca il go-live se trovi accesso non autorizzato a dati, segreti esposti, bucket pubblici non previsti, database raggiungibili, API senza auth, escalation privilegi, pagamenti manipolabili o configurazioni cloud troppo permissive.

Puoi pianificare dopo il lancio solo ciò che ha rischio residuo chiaro, owner definito, scadenza e monitoraggio. Se nessuno possiede il rischio, il rischio non è accettato: è solo rimandato. Una buona decisione di remediation distingue tra difetti funzionali, vulnerabilità sfruttabili, hardening e debito tecnico: non tutto blocca il rilascio, ma ciò che riguarda dati, autorizzazioni, segreti, pagamenti, superfici pubbliche e privilegi deve avere priorità. Il go-live dovrebbe basarsi su finding chiusi o rischi esplicitamente governati, non sulla sola percezione che il prototipo funzioni.

Quando basta una review interna e quando serve una verifica indipendente

Una review interna può bastare per prototipi non pubblici, senza dati reali, senza ruoli, senza API esposte, senza pagamenti, senza integrazioni aziendali e con un reviewer competente sulle aree modificate.

Serve una verifica indipendente quando l’app è online o sta per esserlo, tratta dati reali, ha utenti esterni, gestisce pagamenti, usa ruoli amministrativi, integra API aziendali, espone upload, modifica cloud/IaC o deriva da PR ampie generate da agenti AI. La pressione del go-live non deve sparire: va trasformata in priorità. Prima si controllano dati, autorizzazioni, segreti, superfici esposte e configurazioni di produzione; poi si decide cosa può andare online.

Come ISGroup può verificare un’app generata con AI

Il controllo cambia in base a cosa è stato costruito e a cosa viene esposto. Se l’app o le API sono raggiungibili online, il Web Application Penetration Testing verifica il comportamento reale dall’esterno. Se il rischio è nel codice, nella logica applicativa, nei middleware, nei segreti o nelle dipendenze, la Code Review aiuta a individuare vulnerabilità e regressioni prima della merge. Se il problema riguarda superfici note, host, servizi e configurazioni esposte, il Vulnerability Assessment aiuta a mappare vulnerabilità note e priorità.

Se l’app generata con AI ha…	Rischio principale	Controllo consigliato
Web app, API, route pubbliche, upload, flussi login o pagamento	Comportamenti abusabili dall’esterno	Web Application Penetration Testing
Codice generato, auth, ruoli, business logic, segreti, dipendenze	Vulnerabilità o regressioni nel codice	Code Review
Host, servizi, versioni, configurazioni esposte, endpoint tecnici	Vulnerabilità note o esposizioni tecniche	Vulnerability Assessment
Cloud, IAM, bucket, database, CI/CD, IaC, service account	Misconfiguration o privilegi eccessivi	Cloud Security Assessment
Trust boundary, multi-tenant, integrazioni, dati sensibili	Assunzioni architetturali deboli	Secure Architecture Review
Uso continuativo di AI coding nel ciclo di rilascio	Controlli non ripetibili su release e pipeline	Software Assurance Lifecycle

La scelta del controllo dipende da ciò che è cambiato davvero: codice, comportamento esposto, cloud, architettura o processo di sviluppo. Prima del go-live conviene delimitare quel perimetro e verificare il rischio effettivo sull’applicazione.

Hai creato un’app con strumenti AI e devi collegarla a dati reali, utenti o pagamenti? ISGroup può aiutarti a verificare codice, API, autorizzazioni, segreti, dipendenze, cloud e superfici esposte prima della pubblicazione.

Evidenze da preparare prima della review

Prepara repository o progetto, URL degli ambienti, elenco delle parti generate con AI, ruoli utente, API, provider auth, database, storage, servizi cloud, dipendenze aggiunte, variabili ambiente, log disponibili, pipeline, decisioni di remediation e rischi già accettati. Queste evidenze rendono la verifica più rapida e concreta, perché permettono di distinguere bug applicativi da misconfiguration, problemi di codice da rischi cloud, finding bloccanti da miglioramenti pianificabili.

Domande frequenti

• I test automatici bastano prima del go-live?
• No. Servono, ma non dimostrano da soli che autorizzazioni, tenant isolation, business logic, API e configurazioni siano sicure nel comportamento reale.
• Devo fare sempre WAPT?
• Se l’app o le API sono esposte online, il WAPT è il controllo più diretto sul comportamento esterno. Se invece il rischio è nel codice non ancora esposto, può essere più coerente partire da Code Review.
• Una app no-code o low-code generata con AI è più sicura?
• Non automaticamente. Anche se il codice è nascosto o parzialmente gestito dal vendor, restano configurazioni, auth, ruoli, database, storage, API key, callback e dati reali da verificare.
• Quali finding bloccano il go-live?
• Accesso non autorizzato a dati, escalation privilegi, segreti esposti, database o bucket pubblici non previsti, API senza auth, pagamenti manipolabili e configurazioni cloud troppo permissive.
• Quando serve il Cloud Security Assessment?
• Quando l’app usa cloud, BaaS, database gestiti, storage, IAM, service account, CI/CD, IaC o deploy configurati rapidamente con l’aiuto dell’AI.

Fonti e riferimenti utili

• OWASP Top 10: https://owasp.org/Top10/
• OWASP API Security Top 10: https://owasp.org/www-project-api-security/
• OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
• OWASP Top 10 for LLM Applications 2025: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/
• OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/