“La checklist pre-volo esiste perché la memoria fallisce e il costo di una dimenticanza è l'intero aereo.”
La checklist pre-lancio
Prima del lancio, percorrila una volta, deliberatamente, come farebbe un attaccante. È tutto il corso in forma di lista. Se non fai nient'altro, fai questo:
- Accesso ai dati: ogni tabella ha la Row-Level Security con una policy reale; un secondo utente e una richiesta anonima sono entrambi bloccati (cap. 2).
- Segreti: nessuna chiave segreta nel bundle client o su git; tutto ciò che è trapelato è stato ruotato; le chiavi vivono lato server (cap. 3).
- Autorizzazione: ogni endpoint con id controlla la proprietà sul server; hai provato a cambiare un id e sei stato respinto (cap. 4).
- Superficie esposta: endpoint inventariati, route morte cancellate, CORS ristretto alle tue origin, rate limit su auth e route costose (cap. 5).
- Webhook: ogni webhook in ingresso verifica la firma e rifiuta una chiamata non firmata (cap. 5).
Imposta gli header che lo strumento ha saltato
Gli header di sicurezza sono poche righe di configurazione che attivano protezioni a livello browser, e gli strumenti IA non li aggiungono quasi mai perché senza di loro non si rompe niente. Sono un'assicurazione a basso costo contro intere classi di attacchi:
- Content-Security-Policy: limita quali script e risorse possono caricarsi, smussando il cross-site scripting. Il più prezioso e il più delicato da configurare bene.
- Strict-Transport-Security (HSTS): forza HTTPS così un utente non può essere retrocesso a una connessione intercettabile.
- X-Content-Type-Options: nosniff e X-Frame-Options / frame-ancestors fermano i trucchi sul content-type e il clickjacking via embedding.
- E la base sotto tutti: servi tutto via HTTPS, senza contenuti misti.
Una Content-Security-Policy ragionevole è quella su cui investire davvero: è la differenza tra uno script estraneo che resta inerte e uno che gira con le sessioni dei tuoi utenti. Parti in modalità report-only, così vedi cosa bloccherebbe prima di applicarla.
Le tue dipendenze fanno parte della tua superficie di attacco
Uno strumento IA aggiunge pacchetti a piene mani, e ogni dipendenza è codice di cui ti stai fidando e che stai distribuendo. L'ecosistema IA/JS, in rapido movimento, è terreno fertile per vulnerabilità note, typosquat e librerie abbandonate. L'igiene è standard e vale la pena automatizzarla: fai audit di ciò da cui dipendi, blocca le versioni e correggi i problemi noti prima che vengano sfruttati.
- Esegui una scansione delle vulnerabilità (npm audit, o uno strumento come Dependabot/Snyk) e sistema le critiche prima del lancio.
- Blocca le versioni così una dipendenza non può cambiarti sotto i piedi, e verifica cosa sia davvero un nuovo pacchetto prima di aggiungerlo.
- Mantieni l'abitudine di aggiornare; una dipendenza non mantenuta è una vulnerabilità al rallentatore.
Errori e log: non raccontare gli interni
Le app costruite con l'IA adorano restituire a schermo l'errore grezzo: stack trace, messaggi SQL, percorsi di file. Ognuno è una mappa gratuita dei tuoi interni per un attaccante. Mostra agli utenti un messaggio generico; registra il dettaglio lato server dove solo tu puoi leggerlo. E già che ci sei, assicurati di loggare abbastanza da accorgerti di un attacco: login falliti, autorizzazioni negate, scatti del rate limit.
Quando farsi aiutare
Questo corso rende i buchi comuni e gravi individuabili dalla stessa persona che ha costruito l'app, e per molti progetti eseguire onestamente la checklist basta per lanciare in modo responsabile. Ma più cose gestisci (pagamenti reali, dati sanitari o finanziari, informazioni sensibili di altre persone), più alto è il costo del buco a cui non hai pensato, e più vale la pena far revisionare l'app da qualcuno il cui lavoro a tempo pieno è trovare proprio quelli.
È il lavoro che fa SDEN: hardening e revisione di applicazioni costruite con l'IA proprio contro queste modalità di fallimento, con l'inquadramento SOC 2 / CCPA / PIPEDA che i clienti nordamericani si aspettano. Se hai costruito qualcosa con l'IA e stai per metterci dietro i dati di utenti reali, una security review prima del lancio costa molto meno dell'incidente dopo. Abbinala al corso Sicurezza dell'IA per le minacce specifiche dei modelli, e hai il quadro completo.
Una riga per ciascuno
- Esegui la checklist pre-lancio deliberatamente: accesso ai dati, segreti, autorizzazione, superficie esposta e webhook, tutto il corso in forma di lista.
- Aggiungi le basi che l'IA salta: header di sicurezza (soprattutto una CSP vera), HTTPS/HSTS, scansione delle dipendenze e gestione degli errori che non trapela.
- Riesegui la checklist dopo le modifiche: rigenerare codice con l'IA fa cadere le protezioni in silenzio, quindi la sicurezza è un ciclo, non un traguardo.
- Gli scanner automatici intercettano i buchi meccanici; l'autorizzazione rotta richiede giudizio umano, quindi per i dati sensibili fatti fare una revisione prima del lancio.