Una checklist di sicurezza da eseguire prima di lanciare un'app scritta con l'IA

Come usare questa checklist

State per mettere un'app davanti a clienti veri, e l'avete scritta in gran parte con assistenti di IA. Questo è l'elenco che usiamo noi per decidere se è pronta. È scritto in modo che un titolare possa seguire il ragionamento e uno sviluppatore possa eseguire le prove.

Tre regole di base la fanno funzionare. Prima: chi controlla non deve essere chi ha costruito, e di certo non lo stesso assistente di IA: chi costruisce legge ciò che voleva scrivere, chi controlla legge ciò che c'è. Seconda: provate il comportamento reale: aprite l'app in un browser, create account veri e provate. Terza: tenete traccia. Per ogni controllo annotate data, chi lo ha fatto, cosa è stato provato e l'esito. Quando un cliente vi chiede come è stato rivisto il software, quegli appunti sono la vostra risposta.

Ogni voce qui sotto segue lo stesso schema: perché conta, come provarla e come si presenta un esito positivo. Usate, dove potete, una copia di prova dell'app con dati inventati, e non eseguite mai queste prove su un sistema che non è vostro.

1. I segreti non stanno nel codice

Perché conta. Password, chiavi e codici lasciati nel codice, nelle pagine inviate ai visitatori o nella cronologia dell'archivio possono essere usati da chiunque li trovi, e programmi automatici li cercano di continuo.

Come provarlo.

• Eseguite uno strumento di scansione dei segreti su tutto l'archivio, comprese le versioni passate e non solo i file più recenti. Ne esistono diversi gratuiti.
• Aprite l'app in un browser, guardate il sorgente della pagina e gli script scaricati, e cercate chiavi, codici e password.
• Verificate dove sono conservati i segreti in uso: nelle impostazioni protette del server o in un gestore di segreti, mai nel codice.

Esito positivo. Nessun segreto trovato nel codice né nella sua cronologia, e quelli in uso conservati fuori dal codice. Ogni segreto che sia mai stato esposto è stato sostituito, non solo rimosso, perché togliere una riga non la cancella dal passato.

2. Ogni utente vede solo ciò che deve

Perché conta. L'accesso dimostra l'identità, ma non stabilisce cosa una persona può leggere o modificare. È la falla seria più comune nelle app scritte con l'IA e quella che più spesso fa trapelare i dati di altri clienti.

Come provarlo. Create due account normali, A e B, e un amministratore.

• Come A, aprite un vostro dato e annotate l'indirizzo. Entrate come B e incollate quell'indirizzo: B deve essere respinto.
• Ripetete per ogni tipo di dato: fatture, documenti, messaggi, profili, file caricati.
• Provate la stessa cosa con le azioni invece che con le pagine: B può modificare o cancellare qualcosa di A alterando una richiesta?
• Come utente normale, provate ad aprire direttamente le pagine dell'amministratore digitandone gli indirizzi.
• Uscite e provate ad aprire pagine e file interni senza essere entrati.

Esito positivo. Ogni tentativo di raggiungere i dati di un altro o le funzioni di un ruolo superiore viene respinto, in modo coerente su tutte le schermate. Aiuta anche che le regole siano applicate in un unico punto centrale, così una nuova schermata non può dimenticarle.

3. Accesso e sessioni sono solidi

Perché conta. Una gestione debole dell'accesso permette di indovinare le password, rubare le sessioni o restare collegati dopo che l'utente vero se n'è andato.

Come provarlo.

• Verificate che le password siano conservate in una forma non reversibile, e chiedete come a chi ha costruito l'app. "Con un metodo moderno e lento" è il tipo di risposta giusto.
• Provate più password sbagliate di seguito. L'app deve rallentare o bloccare i tentativi.
• Entrate, poi uscite e premete il pulsante indietro del browser. Non deve ricomparire nulla di privato e la vecchia sessione non deve più funzionare.
• Controllate che le sessioni finiscano dopo un tempo ragionevole, che l'opzione "ricordami" sia limitata e che i link per reimpostare la password scadano e funzionino una volta sola.
• Se offrite la verifica in due passaggi, provate che non si possa saltare andando direttamente alla pagina successiva.

Esito positivo. I tentativi a caso vengono rallentati, le sessioni terminano correttamente, i link di reimpostazione sono monouso e niente di delicato è conservato in un posto che il browser espone.

4. Le richieste al database sono fatte in modo sicuro

Perché conta. Se l'app costruisce le richieste al database incollando ciò che l'utente ha scritto, un visitatore può cambiare la richiesta e leggere o distruggere dati.

Come provarlo.

• Chiedete a chi ha costruito l'app di confermare che ogni richiesta usa parametri, cioè il modo sicuro di passare i valori, e fatevene mostrare qualche esempio.
• Eseguite sul codice uno strumento di analisi statica: segnala le richieste costruite con del testo.
• Scrivete un apostrofo isolato, virgolette e simboli strani nei campi di ricerca e nei moduli. Un'app ben fatta li tratta come testo normale e non mostra mai un errore del database.

Esito positivo. Nessuna richiesta è costruita unendo testo dell'utente, e i dati strani producono un messaggio cortese invece di una pagina di errore.

5. Dati in ingresso e file caricati sono controllati sul server

Perché conta. I controlli che esistono solo nel browser si aggirano in pochi secondi. Tutto ciò che viene mostrato ad altri va ripulito, altrimenti un visitatore può inserire uno script che gira per tutti.

Come provarlo.

• Scrivete un breve frammento innocuo di codice, per esempio del testo fra parentesi angolari, in ogni campo che poi viene mostrato. Deve apparire come semplice testo, non essere interpretato.
• Inviate valori vuoti, molto lunghi e inattesi. Il server deve rifiutarli con garbo.
• Per i file caricati provate un tipo sbagliato, un file molto grande e un file con un nome ingannevole. Devono essere accettati solo i tipi previsti, fino a una dimensione ragionevole.
• Verificate che i file caricati siano conservati lontano dal codice e non vengano mai aperti in un modo che possa eseguirli.

Esito positivo. Il server respinge ciò che non si aspettava, mostra i testi degli utenti in modo sicuro e tratta i file con prudenza.

6. I componenti dell'app sono reali, aggiornati e bloccati

Perché conta. Un'app è fatta soprattutto di componenti di altri. Gli assistenti di IA a volte suggeriscono componenti che non esistono, e chi attacca pubblica sosia dannosi con i nomi inventati. Anche i componenti vecchi hanno debolezze note.

Come provarlo.

• Chiedete l'elenco completo dei componenti e verificate che ciascuno sia reale, diffuso e proveniente dalla fonte ufficiale. Un componente con pochi download e un nome quasi uguale a uno famoso merita sospetto.
• Verificate che le versioni siano bloccate, così un aggiornamento non può arrivare senza che ve ne accorgiate.
• Eseguite il controllo delle dipendenze fornito dalla vostra piattaforma, o uno scanner gratuito, e leggete i risultati.
• Decidete chi è responsabile degli aggiornamenti e con quale frequenza.

Esito positivo. Ogni componente è identificato e motivato, nessuno con una debolezza seria nota è rimasto al suo posto, e qualcuno è responsabile degli aggiornamenti.

7. La configurazione in uso è rinforzata

Perché conta. Le impostazioni di sviluppo lasciate attive in produzione espongono i meccanismi interni: pagine di errore dettagliate, account di prova, strumenti di diagnosi aperti.

Come provarlo.

• Fate fallire l'app di proposito, per esempio aprendo un indirizzo che non esiste o inviando dati sbagliati. L'errore mostrato ai visitatori deve essere breve e generico, con i dettagli conservati in registri privati.
• Verificate che il sito usi ovunque una connessione cifrata e che quelle in chiaro vengano reindirizzate.
• Guardate le intestazioni delle risposte con un controllo online gratuito e verificate che le protezioni standard siano presenti.
• Elencate ogni indirizzo a cui l'app risponde, comprese pagine di amministrazione, percorsi di prova e pagine di stato, e verificate che ciascuno sia voluto e protetto.
• Controllate che l'accesso da altri siti sia limitato a quelli che devono averlo e non aperto a tutti.
• Eliminate gli account predefiniti e di prova.

Esito positivo. La produzione si comporta da produzione: errori silenziosi, traffico cifrato, intestazioni protettive e nessuna porta di prova rimasta aperta.

8. L'app regge gli abusi, non solo l'uso

Perché conta. Un programma può ripetere un'azione migliaia di volte. Senza limiti, un accesso si può indovinare, un modulo di contatto si può usare per inviare spam e una ricerca può rallentare tutto il servizio.

Come provarlo.

• Inviate la stessa richiesta molte volte in rapida successione ai moduli di accesso, iscrizione, recupero password e contatto. L'app deve rallentare, rifiutare o richiedere una prova in più dopo una soglia.
• Cercate le funzioni che inviano email o messaggi per conto dei visitatori e verificate che siano limitate e non si possano indirizzare a terzi.
• Controllate che i moduli pubblici abbiano semplici protezioni contro l'invio automatico, come limiti per visitatore e un campo nascosto che una persona non compila mai.
• Verificate che l'app registri i tentativi falliti, in modo che si possano vedere.

Esito positivo. La ripetizione viene rallentata o fermata, i moduli non si possono rivolgere contro altre persone e gli abusi lasciano una traccia.

9. I dati personali sono ridotti, protetti e conosciuti

Perché conta. La legge si aspetta che sappiate quali dati personali conservate, perché li conservate e per quanto tempo. Un prototipo non fa eccezione.

Come provarlo.

• Fate un elenco semplice di ogni tipo di dato personale che l'app raccoglie, dove è conservato e chi può vederlo. Se non riuscite a farlo, è già il primo problema trovato.
• Togliete ciò che non serve. Un dato mai raccolto non può trapelare.
• Controllate i registri: non devono contenere password, dati completi di carte o schede personali intere.
• Verificate che le copie di sviluppo e di prova usino dati inventati e che nessuno abbia incollato dati veri di clienti in uno strumento di IA per rendere una prova più realistica.
• Accertatevi che l'informativa sulla privacy corrisponda a ciò che l'app fa davvero e che esista un modo per cancellare o esportare i dati di una persona su richiesta.

Esito positivo. Sapete dire cosa conservate e perché, i registri sono puliti, gli ambienti di prova usano dati finti e l'informativa è veritiera.

10. Si può ripartire, e lo avete dimostrato

Perché conta. L'incidente di sicurezza peggiore è quello da cui non ci si riprende. Un backup mai ripristinato è una speranza, non un piano.

Come provarlo.

• Verificate che i backup partano da soli, che siano conservati lontano dal server in uso e che siano protetti da manomissioni.
• Ripristinatene davvero uno in un ambiente pulito e controllate che l'app si avvii e che i dati siano completi. Cronometrate quanto ci vuole.
• Scrivete, in poche righe, cosa fare se l'app viene attaccata o i dati vanno persi: chi si chiama, cosa si spegne, chi avvisa i clienti e chi avvisa le autorità se sono coinvolti dati personali.
• Controllate che l'app registri abbastanza da ricostruire cosa è successo: chi è entrato, chi ha cambiato cosa e quando.

Esito positivo. Un ripristino provato, un breve piano scritto e registri che permettono di ricostruire gli eventi.

Farne un'abitudine, e chi fa cosa

Una revisione isolata invecchia in fretta, perché ogni nuova funzione può riaprire un vecchio problema. Poche abitudini mantengono viva la checklist senza trasformarla in un progetto.

• Eseguire i controlli automatici a ogni modifica. Scansione dei segreti, dei componenti e analisi statica si possono inserire nel processo che pubblica l'app, così un esito negativo ferma il rilascio.
• Tenere le modifiche piccole. Le grandi modifiche generate dall'IA sono le più difficili da rivedere. Chiedete il lavoro a pezzi che una persona riesca a leggere.
• Ripetere i punti 2, 3 e 8 dopo ogni modifica importante a permessi, accesso o moduli pubblici. Sono quelli che una riscrittura rompe più facilmente.
• Fissare una data. Rifare l'intero elenco ogni pochi mesi e dopo ogni incidente, conservando insieme gli appunti datati.
• Separare i ruoli. Una persona o un gruppo costruisce, un altro rivede, il titolare approva. Per le app che trattano pagamenti o dati delicati, o nei settori regolamentati, coinvolgete un professionista esterno.

Cosa questa checklist non copre

Nessun elenco è completo. Questo è volutamente concentrato sui problemi più comuni nelle app scritte con l'IA e che un gruppo attento, anche non specialista, riesce a provare. Non sostituisce un test di intrusione fatto da specialisti, una verifica dei vostri obblighi di legge o gli standard particolari del vostro settore. Consideratelo la soglia minima ragionevole prima del lancio e un modo per avere una conversazione migliore con chi farà la verifica più approfondita.

Se volete un secondo paio d'occhi su un'app costruita così, possiamo eseguire i controlli sull'applicazione in funzione e consegnarvi una relazione in linguaggio semplice: cosa va bene, cosa va corretto prima del lancio e cosa può aspettare.

Domande frequenti

Foto: Ann poan su Pexels