Checklist di sicurezza per app create con l'AI: cosa controllare prima del lancio

Prima che persone reali usino un'app creata con l'AI, controlla sette cose: ogni pagina e ogni API verifica chi è l'utente e cosa gli è permesso fare; le chiavi segrete stanno sul server, mai nel browser o nella chat; tutti gli input vengono validati sul server; ogni utente può raggiungere solo i propri record; l'accesso e gli endpoint costosi hanno dei rate limit; le dipendenze sono aggiornate; e puoi ripristinare i tuoi dati se qualcosa va storto. La checklist qui sotto trasforma ciascuno di questi punti in test specifici che puoi eseguire senza leggere il codice.

I builder di app AI sono bravi a far funzionare le funzioni. Non sono automaticamente prudenti, perché la «prudenza» raramente è nel prompt. La maggior parte dei problemi che seguono nasce da cose che nessuno ha chiesto, quindi la soluzione di solito è chiederle.

Come usare questa checklist

Segui l'elenco in ordine e, per ogni voce, fai due cose: chiedi all'AI di assicurarsi che sia gestita, e testala tu stesso. L'AI può scrivere un controllo dei permessi; solo un test ti dice che funziona. Le voci sono contrassegnate così:

• Obbligatorio — da fare prima che chiunque altro usi l'app.
• Consigliato — da fare prima di avere utenti reali o dati reali.
• Più avanti — utile man mano che l'app cresce.

Se hai solo un'ora, fai tutti gli Obbligatori.

1. Autenticazione: chi è?

L'autenticazione significa confermare chi è una persona, di solito tramite login. Vedi cos'è l'autenticazione per le basi e come aggiungere il login alla tua app per le opzioni.

• Obbligatorio: ogni pagina che mostra dati privati richiede il login. Test: esci dall'account, poi incolla direttamente nel browser l'URL di una pagina privata.
• Obbligatorio: ogni endpoint API dietro a quelle pagine richiede anch'esso il login, non solo la pagina. Test: esci dall'account, apri la scheda di rete del browser e ripeti una richiesta che l'app ha fatto mentre eri connesso.
• Obbligatorio: le password sono memorizzate con hash usando un algoritmo di hashing lento, mai in chiaro. Le linee guida OWASP sulla memorizzazione delle password raccomandano prima Argon2id, con scrypt, bcrypt o PBKDF2 come alternative. Chiedi: «Come vengono memorizzate le password?»
• Consigliato: i link per reimpostare la password scadono e funzionano una sola volta.
• Consigliato: i cookie di sessione sono marcati Secure, HttpOnly e SameSite, e il logout termina la sessione sul server.
• Più avanti: offri l'autenticazione a due fattori, o l'accesso tramite un provider che la supporta.

Controlla ogni route API e ogni pagina che restituisce dati utente. Ciascuna deve rifiutare le richieste di utenti non connessi, sul server, non solo nel codice della pagina. Elenca le route che hai controllato.

2. Autorizzazione: cosa può fare?

L'autorizzazione è il passo successivo al login: decidere cosa questo specifico utente può vedere e modificare. È qui che le app create con l'AI hanno più spesso falle gravi, perché l'app sembra corretta — la dashboard di ogni utente mostra solo i suoi dati — mentre il server consegnerebbe i dati di chiunque se glieli si chiede direttamente.

• Obbligatorio: ogni lettura, aggiornamento e cancellazione verifica, sul server, che il record appartenga all'utente corrente (o al suo team).
• Obbligatorio: testalo. Crea due account, A e B. Come A, apri uno dei record di A e annota l'ID nell'URL o nella richiesta di rete. Accedi come B e richiedi lo stesso ID. B deve ricevere un errore, non i dati di A.
• Obbligatorio: le pagine e gli endpoint API di amministrazione verificano il ruolo dell'utente sul server. Nascondere il link admin non è una protezione.
• Obbligatorio: gli utenti non possono cambiare il proprio ruolo, prezzo, saldo o campi proprietario modificando la richiesta. Test: nella scheda di rete, guarda cosa invia un aggiornamento del profilo. Se include campi come role o isAdmin, chiedi all'AI di ignorarli dal client.
• Consigliato: gli ID negli URL sono difficili da indovinare (ID casuali invece di 1, 2, 3). Non sostituisce i controlli dei permessi, ma limita il danno quando uno manca.

Per ogni endpoint che legge o modifica un record, verifica sul server che l'utente connesso ne sia il proprietario o possa accedervi. Se no, restituisci 404. Poi mostrami come lo testeresti con due account.

3. Accesso a livello di riga nel database

«Accesso a livello di riga» significa che ogni riga di una tabella (una prenotazione, una fattura) è visibile solo agli utenti a cui appartiene. Ci sono due approcci comuni per applicarlo:

Entrambi si possono fare bene. Ciò che conta:

• Obbligatorio: se il browser parla direttamente con il database (alcuni prodotti di database ospitati lo permettono), le regole a livello di riga sono attive per ogni tabella. Senza, chiunque abbia la chiave pubblica può leggere l'intera tabella.
• Obbligatorio: le query filtrano per utente o team corrente, non per un ID inviato dal browser.
• Consigliato: i dati condivisi (i progetti di un team) hanno una regola chiara su chi fa parte del team, applicata in un solo punto.

4. Segreti e chiavi API

Una chiave API è una password per un servizio. Stripe, le email e i provider di AI usano tutti chiavi di questo tipo. Per un approfondimento, vedi cosa sono le variabili d'ambiente e i segreti.

• Obbligatorio: le chiavi sono memorizzate nelle variabili d'ambiente o nei segreti del progetto, mai scritte nel codice.
• Obbligatorio: le chiavi che possono spendere denaro o leggere dati privati sono usate solo sul server. Test: apri il tuo sito dal vivo, visualizza il sorgente della pagina e i file JavaScript negli strumenti di sviluppo, e cerca l'inizio della tua chiave (per esempio sk_). Non deve comparire.
• Obbligatorio: le chiavi non sono mai state incollate in chat, in un repository pubblico o in uno screenshot. Se è successo, ruotala presso il provider (creane una nuova ed elimina quella vecchia).
• Consigliato: usa chiavi ristrette o con ambito limitato dove il provider le offre. Stripe, per esempio, consiglia chiavi ristrette che abbiano solo i permessi di cui la tua integrazione ha bisogno.
• Consigliato: le chiavi di test e quelle live sono separate, e l'app live usa le chiavi live solo quando sei pronto.

Alcune chiavi sono pensate per essere pubbliche — la chiave pubblicabile di Stripe (pk_…) o una chiave per le mappe limitata al tuo dominio. La regola riguarda le chiavi che conferiscono potere, non ogni stringa che sembra una chiave.

5. Validazione degli input

Qualsiasi cosa un utente invii — campi di moduli, caricamenti di file, parametri URL — può essere qualsiasi cosa, non solo ciò che il tuo modulo consente.

• Obbligatorio: la validazione avviene sul server, non solo nel browser. I controlli nel browser servono per comodità; chiunque può saltarli.
• Obbligatorio: le query al database usano parametri, non testo composto incollando l'input dell'utente (questo previene la SQL injection). Chiedi all'AI di confermarlo.
• Obbligatorio: il testo inserito dagli utenti viene mostrato come testo, non eseguito come HTML. Test: inserisci <b>ciao</b> come nome. Dovresti vedere i tag, non il testo in grassetto.
• Consigliato: i caricamenti di file controllano tipo e dimensione, e i file caricati non vengono serviti dal dominio principale dell'app come pagine eseguibili.
• Consigliato: gli errori mostrati agli utenti sono semplici («Qualcosa è andato storto»); i dettagli vanno solo nei log del server.
• Consigliato: i webhook di servizi come Stripe verificano la firma del provider prima di agire. Vedi cos'è un webhook.

Aggiungi la validazione lato server a ogni modulo e ogni endpoint API: campi obbligatori, lunghezze, formati e valori ammessi. Rifiuta tutto il resto con un messaggio chiaro. Non mostrare agli utenti i dettagli interni degli errori.

6. Rate limit e abusi

Un rate limit limita quante richieste una persona può fare in un periodo. Senza, chiunque può indovinare password tutto il giorno, inondare il tuo modulo di registrazione o far lievitare la bolletta di un'API a pagamento.

• Obbligatorio: login, registrazione e reimpostazione della password hanno un rate limit per indirizzo IP e per account.
• Obbligatorio: ogni cosa che ti costa denaro per chiamata — richieste ai modelli AI, SMS, email — ha un limite per utente e richiede il login.
• Consigliato: i moduli pubblici (contatto, lista d'attesa) hanno una protezione antispam: un rate limit, un campo honeypot nascosto o un CAPTCHA.
• Consigliato: imposta limiti di spesa o avvisi presso i provider a pagamento, così un bug o un attaccante non può generare una bolletta illimitata.

7. Dipendenze

Le app sono costruite a partire da pacchetti open source, e i pacchetti a volte hanno vulnerabilità note.

• Consigliato: chiedi all'AI di verificare le vulnerabilità note (per i progetti JavaScript, npm audit o l'equivalente del tuo package manager) e di aggiornare ciò che è interessato.
• Consigliato: rimuovi i pacchetti che l'app non usa più.
• Consigliato: diffida dei pacchetti con pochissimi utenti o con nomi che sembrano refusi di quelli popolari.
• Più avanti: ricontrolla ogni uno o due mesi, o attiva gli avvisi automatici se il tuo codice è su GitHub.

8. Backup e ripristino

La sicurezza include la capacità di recuperare dagli errori — tuoi, dell'AI o di un attaccante.

• Obbligatorio: sai dove si trovano i tuoi dati e se sono sottoposti a backup. Non darlo per scontato; controlla la documentazione del tuo host.
• Consigliato: conserva un'esportazione periodica dei dati importanti (per esempio una funzione di esportazione CSV o un dump del database), in un luogo separato.
• Consigliato: conserva il codice in un sistema di controllo di versione, così puoi ripristinare qualsiasi versione.
• Consigliato: le azioni distruttive (eliminare un account, eliminare un progetto) chiedono conferma, e valuta una «cancellazione reversibile» che si può annullare per un certo periodo.
• Più avanti: prova davvero un ripristino almeno una volta. Un backup che non hai mai ripristinato è una speranza, non un piano.

9. Prima del lancio

• Obbligatorio: il sito live usa HTTPS ovunque.
• Obbligatorio: i dati di esempio, gli account di test e le pagine di debug dello sviluppo sono rimossi.
• Consigliato: un'informativa sulla privacy spiega quali dati raccogli e perché — in molti paesi è obbligatoria se raccogli dati personali. Non dichiarare certificazioni (SOC 2, HIPAA) che non possiedi.
• Consigliato: hai un modo per essere contattato per problemi di sicurezza, e sai come ruotare rapidamente ogni chiave.

Per un controllo pre-lancio più ampio, oltre la sicurezza, vedi come portare un prototipo AI in produzione.

Quando chiedere una revisione professionale

Una checklist intercetta gli errori comuni; non sostituisce un esperto. Valuta una revisione a pagamento se elabori tu stesso i numeri di carta invece di usare un checkout ospitato, conservi dati sanitari, finanziari o di minori, vendi ad aziende che chiedono questionari sulla sicurezza, o subiresti danni seri in caso di fuga di dati. Avere il codice esportabile rende molto più facile quella revisione.

La sicurezza quando si costruisce su Mythex

Mythex non include un pannello di scansione della sicurezza, quindi il processo da seguire è la checklist qui sopra. Alcune cose che aiutano:

• Segreti del progetto. Memorizza le chiavi in impostazioni del progetto → Segreti, oppure tramite la scheda dei segreti che l'agente mostra in chat, così restano fuori dal codice e dai messaggi. Dopo aver cambiato un segreto di un'app live, pubblica di nuovo.
• Modalità Plan e Ask. Chiedi all'agente di controllare i permessi senza modificare nulla: «In modalità Ask, elenca ogni route API e quale controllo dei permessi esegue».
• /test fa cliccare all'agente la tua anteprima come utente — utile per il test con due account della sezione 2.
• I checkpoint ti permettono di annullare una modifica che ha rotto qualcosa.

Vedi Sicurezza per le app che crei e Variabili d'ambiente e segreti nella documentazione. Se stai per aggiungere account utente, leggi come aggiungere il login alla tua app.

Domande