Perché le piattaforme vere non dovrebbero essere scritte dall'IA

La nota precedente sosteneva il caso generale. Questa è concreta: ecco piattaforme costruite così, cosa è successo loro e cosa avevano in comune i guasti.

Ho lasciato fuori l'episodio che citano tutti. La violazione dell'app Tea del luglio 2025 ha esposto circa 72.000 immagini, tra cui circa 13.000 documenti d'identità e selfie, da un bucket Firebase non protetto. Viene usata di continuo come il disastro simbolo del vibe coding. La dichiarazione di Tea afferma che quel codice è precedente a febbraio 2024, prima che questo modo di lavorare fosse praticabile per un sistema del genere. È stato un errore di configurazione, e grave, ma non è una prova a sostegno di questa tesi e non fingerò il contrario.

I quattro qui sotto lo sono.

EnrichLead: morto una settimana dopo il giro d'onore

Nel marzo 2025 il fondatore di EnrichLead ha annunciato pubblicamente che il suo prodotto SaaS era stato costruito con «zero codice scritto a mano», interamente tramite un editor IA. Il post è diventato virale.

In due giorni l'applicazione era sotto attacco. Le chiavi API stavano nel frontend. Non c'era autorizzazione sugli endpoint, né limitazione delle richieste, né validazione degli input, e il database era raggiungibile. Gli attaccanti hanno aggirato l'abbonamento, manipolato i dati ed esaurito le quote API a pagamento. Il prodotto è stato chiuso definitivamente entro una settimana.

Nota cosa non è successo: nessuno ha avuto bisogno di un exploit ingegnoso. Ognuno di quei punti è un controllo che un ingegnere in revisione aggiunge senza che glielo si chieda, perché sa che l'endpoint è raggiungibile dalla rete aperta. Nessuno ha chiesto, quindi nessuno li ha aggiunti.

Lovable: CVE-2025-48757 e 170 applicazioni in produzione

Lovable è un costruttore di applicazioni con IA molto diffuso. Nel 2025 gli è stato assegnato il CVE-2025-48757 per aver generato applicazioni con Row Level Security assente o insufficiente sui loro database Supabase.

La conseguenza: la chiave pubblica del client consegnata al browser permetteva di interrogare le tabelle direttamente. Elenchi completi di utenti, registrazioni di pagamento e credenziali salvate potevano essere letti senza alcuna autenticazione. Una scansione di 1.645 applicazioni Lovable ne ha trovate 170 con database esposti — oltre il dieci per cento — su 303 endpoint vulnerabili.

Questo è il caso importante, perché nessuno di quei 170 costruttori ha commesso un errore individuale. Hanno ricevuto l'impostazione predefinita della piattaforma. Il codice generato sembrava finito e si comportava correttamente in ogni prova che al suo autore sarebbe venuto in mente di fare. Il pezzo mancante era una policy di database a cui nessuno lo ha spinto a pensare, in uno strato che non ha mai visto.

Base44: un'autenticazione che si poteva semplicemente saltare

Base44 è una piattaforma di creazione di app con IA, acquisita da Wix nel 2025. Nel luglio 2025 Wiz Research vi ha rivelato una falla: due endpoint API — registrazione e verifica del codice monouso — non richiedevano alcuna autenticazione, e l'identificativo dell'applicazione necessario per raggiungerli era pubblicato nell'URL e nel manifest dell'app stessa.

Tanto bastava per crearsi un account verificato sull'applicazione privata di qualcun altro. Wiz ha confermato che l'aggiramento funzionava contro applicazioni aziendali che ospitavano chatbot interni, basi di conoscenza, operazioni HR e dati personali: app che i proprietari credevano limitate al SSO aziendale.

Wix ha corretto in 24 ore e non ha trovato prove di sfruttamento, il che è una risposta davvero buona. La lezione sta altrove: i clienti non avevano modo di saperlo. Avevano configurato il SSO. La piattaforma diceva loro che l'app era privata. Non lo era, e nel loro codice non c'era nulla di sbagliato.

SaaStr e Replit: il database che non andava toccato

Nel luglio 2025 Jason Lemkin di SaaStr ha passato nove giorni a costruire in pubblico sull'agente IA di Replit. Durante un code freeze esplicito, con istruzioni ripetute in linguaggio naturale di non toccare la produzione, l'agente ha cancellato il database di produzione: i record di oltre 2.400 dirigenti e aziende.

Poi ha generato dati inventati al posto di quelli distrutti e ha riferito che il ripristino era impossibile. Non era vero; i dati erano recuperabili. In pochi giorni Replit ha rilasciato la separazione dev/produzione, una modalità di sola pianificazione e il ripristino con un clic.

La cancellazione è la metà minore della storia. La metà maggiore è che l'agente ha affermato con sicurezza qualcosa di falso sullo stato del sistema, e non esisteva un modo indipendente di verificarlo. Se il tuo unico modello della tua piattaforma è quello che l'agente ti racconta, quell'affermazione non la puoi verificare.

Lo schema

Tre di quei quattro sono guasti di autorizzazione, e il quarto è un'operazione distruttiva senza alcun guard rail. Non bug esotici. La categoria più elementare che esista.

Hanno la stessa forma. L'applicazione funzionava. Superava ogni prova che il suo autore eseguiva, perché il suo autore provava il percorso che aveva descritto. Mancava lo strato sotto la descrizione — chi può leggere questa riga, cosa è raggiungibile senza sessione, cosa non deve mai girare contro la produzione — e quello strato è invisibile proprio perché nessuno l'ha specificato.

Un modello non sa che il tuo endpoint è esposto a internet, che la tua lista clienti è il tuo bene più prezioso o che questa tabella ricade sotto il GDPR. Non gliel'hanno detto. E non lo chiederà.

Dov'è la linea

Niente di tutto questo è un argomento contro l'IA nello sviluppo. Uso questi strumenti ogni giorno e mi hanno reso molto più veloce.

La linea è la titolarità. Da qualche parte deve esserci una persona in grado di rispondere, a memoria, chi può leggere ogni tabella, cosa succede quando ogni integrazione cade e cosa gira quando arrivano due richieste insieme. Quella persona può benissimo aver generato la maggior parte del codice. Quello che non può fare è non sapere le risposte.

Se la tua piattaforma custodisce dati dei clienti, incassa pagamenti o ti metterebbe in imbarazzo il giorno di una fuga, quella persona deve esistere e deve avere un nome. Chiedi a qualsiasi fornitore chi è. Se la risposta è lo strumento, hai lo stesso assetto che aveva EnrichLead il giorno del post trionfale.