Perché le app costruite con l'IA escono insicure

“Un impresario che costruisce esattamente quello che descrivi, in fretta, e non nomina mai le norme edilizie, perché non gliel'hai chiesto.”

Il divario tra 'funziona' e 'è sicuro'

Chiedi a uno strumento IA di costruire una funzionalità e ottimizzerà per ciò che puoi vedere: la schermata si carica, il pulsante invia, i dati compaiono. Quella è la demo, e la demo passa. La sicurezza è la parte che nella demo non si vede: il controllo che impedisce a un utente di leggere i dati di un altro, la chiave che non dovrebbe stare nel browser, l'endpoint che dovrebbe rifiutare una richiesta non autenticata. Niente di tutto questo cambia l'aspetto del percorso felice, quindi niente viene costruito a meno che qualcuno non lo chieda.

Non è una critica agli strumenti. È la descrizione di ciò per cui sono stati addestrati: produrre codice che soddisfa la richiesta. "Costruiscimi una dashboard dove gli utenti vedono i propri ordini" produce una dashboard dove gli utenti vedono i propri ordini. Non produce "...e dove l'utente A non può, in modo dimostrabile, raggiungere gli ordini dell'utente B", perché non l'hai detto, e nella demo, con un solo utente loggato, la differenza è invisibile.

Perché il modello lascia i buchi

Tre forze si sommano. Il modello riempie con il pattern più comune dei suoi dati di addestramento, e gran parte di quei dati sono tutorial e codice quick-start mai pensati per la produzione. Non ha alcuna visione del tuo modello di minaccia: non sa se questo è un progetto hobbistico o se gestisce dati di pagamento. E ogni giro di prompting può silenziosamente annullare una protezione aggiunta in un giro precedente, perché il modello ottimizza la richiesta corrente, non preserva quella passata. Perché superare la demo non dice nulla sulla sicurezza.↗

Una violazione reale, nel dettaglio

Nel 2025 un ricercatore di sicurezza, Matt Palmer, ha scandagliato 1.645 applicazioni costruite sulla piattaforma IA Lovable e ha trovato 303 endpoint insicuri in 170 di esse (circa una su dieci) dove chiunque poteva leggere, modificare o cancellare qualsiasi riga del database. I dati esposti includevano nomi, numeri di telefono, dettagli di pagamento e chiavi API. La causa non era esotica: le app generate parlavano al database direttamente dal browser, senza regole di accesso a livello di riga. È diventata la CVE-2025-48757, classificata critica (CVSS 9.3).

Niente in quelle 170 app sembrava rotto. Sono uscite, funzionavano, utenti reali si sono registrati. Il buco era strutturale e invisibile dal front end, esattamente il tipo di divario di cui parla questo corso. I numeri che circolano accanto a storie come questa ("X milioni di chiavi trapelate") sono spesso non verificati; la CVE documentata basta da sola a fare il punto.

I cinque buchi, e il resto di questo corso

La buona notizia: i buchi non sono infiniti né misteriosi. Le app costruite con l'IA perdono dati in un numero ristretto di punti prevedibili, e ciascuno corrisponde a un capitolo:

• Accesso ai dati: il database si fida del browser, quindi qualsiasi utente può raggiungere qualsiasi riga (capitolo 2).
• Segreti: chiavi API e credenziali finiscono nel codice client o su git (capitolo 3).
• Autorizzazione: il login esiste, ma i controlli di proprietà per risorsa no (capitolo 4).
• Superficie esposta: endpoint dimenticati, API aperte e webhook non verificati (capitolo 5).
• Tutto il resto prima del lancio: header, dipendenze, errori e la checklist che intercetta quel che rimane (capitolo 6).

Affrontali in ordine e chiuderai i divari che hanno prodotto incidenti come la CVE di Lovable. Niente di tutto questo richiede di essere uno specialista di sicurezza. Richiede di conoscere i cinque punti dove guardare e cosa significa "fatto" in ciascuno.