Ha trovato una porta aperta nel mio sito. Ecco la correzione

Punta REA sulla tua app prima che qualcun altro la smonti. Noi lo abbiamo puntato sul nostro sito live da una sandbox cloud usa e getta, abbiamo corretto ciò che ha trovato e abbiamo spedito la pull request.

REA è la skill di reverse engineering che un'intera ondata di video ha puntato sul software di qualcun altro. Sul nostro sito ci sono volute meno di tredici minuti e nemmeno una richiesta di scrittura per dimostrare che qualsiasi sito web poteva riempire la nostra mailing list. Ha anche trovato il limite giornaliero del nostro bot dei commenti dentro il JavaScript che si scarica dal nostro sito. Dopo la correzione, la richiesta che prima passava viene rifiutata.

Il risultato sono sei regole per fare lo stesso audit sulla tua app: la sandbox usa e getta, l'obiettivo esatto, lo smistamento dei risultati, la config nel tuo bundle, i freni sugli endpoint e la prova della correzione.

REA sta per Reverse Engineer Anything: un insieme di strumenti che permette a Claude Code di smontare l'app che pubblichi. Fare reverse engineering significa capire come è costruita una cosa partendo dal prodotto finito, come un meccanico che legge un'auto senza i disegni di fabbrica.

Invece di leggere il tuo codice sorgente, REA legge il bundle, cioè il JavaScript che il tuo sito invia davvero a ogni visitatore. Da quel bundle elenca le route, gli endpoint che le tue pagine chiamano e tutto ciò che hai lasciato dentro per errore. Non può restituirti il sorgente, perché ottieni solo prove, e la sua stessa documentazione dice che non è nemmeno una sandbox.

Per installarlo:

1. Installa REA dal suo pacchetto ufficiale e fissa la versione, perché ha pubblicato sei release in una settimana.
2. Lancia il suo setup per Claude Code.
3. Attiva il profilo compact, perché carica ben più di cento strumenti nella tua sessione.
4. Installa solo dal repo ufficiale, perché sono già circolate copie false con malware dentro.

Quando abbiamo eseguito l'installazione nella nostra sandbox, l'agente ha prima verificato che il pacchetto puntasse al repo ufficiale, prima di toccare qualsiasi cosa. Il setup ha poi installato la skill ma nessun server di strumenti, così Claude Code ha semplicemente usato le versioni da riga di comando degli stessi strumenti di REA. Se dopo il setup i tuoi strumenti non compaiono, non devi riavviare nulla: richiama gli stessi passaggi dal terminale.

La prima regola riguarda dove lo lanci. Stai per lasciare che un agente guidi un browser ed esegua strumenti scaricati contro la tua app in produzione. Sul tuo portatile, quell'agente sta accanto alle tue chiavi, ai tuoi altri progetti e a ogni account a cui sei collegato. Le note di sicurezza di REA lo dicono chiaramente: non è una sandbox.

Una sandbox è una macchina usa e getta, quindi qualsiasi cosa vada storta resta lì dentro e tu la elimini. Apri una sandbox usa e getta sul tuo repo e lancia lì tutto l'audit, mai sulla tua macchina.

Noi abbiamo usato Kosuke, che esegue Claude Code sul tuo abbonamento dentro una macchina cloud usa e getta. Scegli il tuo repo, dici al deploy agent come si avvia la tua app e ti dà una preview, un link dove compare la tua app in esecuzione. Ogni chat ha anche un proprio branch, cioè la sua copia del codice, e finisce con una pull request. Quando abbiamo importato il nostro sito, l'agente ha installato il package manager e un browser headless, ha misurato la memoria e ha scelto da solo la taglia della macchina. Pochi minuti dopo il nostro sito reale girava accanto alla chat, su un branch che nessun altro tocca.

Una trappola di un test precedente: una app Next.js nuova compariva nella preview, ma nulla nella pagina rispondeva. La soluzione è una riga nella tua config Next che autorizza l'indirizzo della preview, e la pagina si anima.

Il limite è che questo è lo stesso Claude Code con una scatola intorno, quindi una macchina virtuale locale o un container fanno lo stesso lavoro. Conta la scatola, non la marca.

Disclosure: Kosuke ci ha dato accesso gratuito al suo piano top. Inserisci il codice AIDIVE2026 nel campo "Promo code" subito dopo l'iscrizione e ottieni trenta dollari di crediti invece dei soliti dieci.

La seconda regola è ciò che dici davvero a REA. Se dici solo "fai l'audit della mia app", la skill di REA si ferma e chiede quale app.

REA non apre mai un browser da solo, quindi ne avvii uno tu con una porta di debug, una porta che permette a uno strumento di osservare tutto ciò che fa la pagina. Prepara tutto in quest'ordine:

1. Tieni la porta di debug sul loopback, l'indirizzo raggiungibile solo dalla tua macchina, e dai al browser un profilo nuovo.
2. Blocca ogni richiesta di scrittura prima che si carichi qualsiasi pagina, così l'audit può leggere il tuo sito ma non può inviare un modulo né cambiare nulla.
3. Solo allora dai a REA le pagine esatte che vuoi fargli leggere.

Nel nostro prompt abbiamo indicato due pagine del nostro club gratuito e scritto una regola in parole semplici: non inviare mai una scrittura al sito live. Contava, perché il modulo di quelle pagine alimenta una vera mailing list con persone vere. L'agente ha preso sul serio la regola e ha scritto da sé una piccola guardia che lasciava passare le letture e fermava tutto il resto. Durante l'audit, quella guardia ha fermato sei tentativi dello script di analytics, e nemmeno una richiesta è mai arrivata al nostro modulo di iscrizione.

REA ha poi fatto la sua parte: ispezionare ogni pagina, leggere ogni bundle, fare screenshot ed esportare gli script fuori dal repo.

Il limite è che REA osserva solo ciò che si carica mentre è collegato, quindi tutto ciò che è successo prima resta un'incognita nel report. Anche così, ora hai un report sulla tua app live, scritto senza toccare un solo dato.

La terza regola è smistare prima di correggere. Un report così è pieno di righe allarmanti e vorrai correggerle tutte insieme.

La skill di REA vuole che ogni conclusione sia segnata come osservazione, inferenza o incognita, con un ID di evidenza. È ciò che ha visto, ciò che ha ipotizzato e ciò che non poteva vedere, e l'ID di evidenza è una ricevuta che puoi verificare. Smista prima ogni risultato così, usando solo il punto di vista di un esterno, e fai il commit di quella versione prima di aprire un solo file sorgente. Poi leggi il tuo sorgente e segna ogni riga come perdita reale, come voluta o come falso positivo.

Il nostro report aveva quindici risultati:

Risultato	Cosa ha visto REA	Il nostro verdetto
Endpoint di iscrizione	Nessun limite e nessun controllo su quale sito chiamasse, quindi qualsiasi sito poteva far iscrivere alla nostra lista, dal browser di un visitatore, qualsiasi indirizzo	Perdita reale, la peggiore
Gate email sui pack gratuiti	L'intero pack è già nella pagina che carichi; una riga nella console del browser toglie il gate, oppure la modalità lettura mostra il testo	Voluto
Source map, chiavi, cookie	Nessuno nei bundle, nessun cookie da nessuna parte	Buone notizie

Il gate è voluto perché i pack sono gratuiti di proposito, e il nostro stesso codice dice che un modulo rotto non deve mai nascondere una pagina gratuita.

Il limite è la colonna delle incognite. REA non vede cosa fa il tuo server, quindi chiudi quelle righe leggendo il codice del tuo server.

La quarta regola riguarda ciò che trasporta il tuo bundle, perché un solo file di impostazioni condiviso può arrivare a ogni visitatore senza che te ne accorga.

Ecco come succede. Importi la config in un helper, e due piccoli componenti interattivi usano quell'helper. Il bundler, lo strumento che impacchetta il tuo codice nei file scaricati dal browser, non sa quali chiavi servano loro, quindi le spedisce tutte.

È esattamente ciò che REA ha trovato nel nostro JavaScript. L'intera config del sito stava in un solo file, con l'ID della nostra mailing list, le nostre cartelle di build e i limiti del bot che risponde ai commenti sui nostri video. Diceva persino quante risposte invia al giorno quel bot, cento, e quanti errori fanno scattare il suo interruttore di sicurezza. I due componenti che la importavano leggevano solo il nome del sito e l'elenco delle lingue.

La regola: cerca nel tuo JavaScript pubblicato le chiavi della tua config e dai ai componenti client solo i campi che leggono. Nella nostra sandbox, l'agente ha diviso la config in una versione minuscola per il browser con solo quei campi, e il resto è rimasto sul server. Ha anche aggiunto uno step di build che fallisce se una chiave del server compare di nuovo in un file pubblicato, così non si può tornare indietro.

Niente di tutto questo era una password, ma tutto ciò che sta in quel file è pubblico, quindi i tuoi segreti vivono solo in variabili del server.

La quinta regola ha corretto la nostra vera perdita, e vale ogni volta che hai un modulo pubblico che chiama un servizio a pagamento: la tua lista email, il tuo modello AI o il tuo gateway di SMS. Lo chiami tramite una piccola funzione server scritta in un pomeriggio. La nostra prendeva un'email e la passava dritta alla mailing list, e qualsiasi altro sito poteva far inviare quella richiesta al browser di un visitatore.

La checklist stessa del mondo della sicurezza lo dice chiaramente: il tuo controllo degli accessi funziona solo in codice che l'attaccante non può cambiare, cioè il tuo server. Quindi metti freni su ogni endpoint così:

• Controllo dell'Origin. L'header Origin è il timbro che un browser mette su una richiesta per dire quale sito l'ha inviata, così un modulo su un altro sito viene rifiutato.
• Rate limit. Un tetto al numero di richieste che un visitatore può inviare in una finestra breve.
• Consenso verificato sul server. La casella che spunti viaggia davvero con la richiesta.

Nella nostra sandbox, l'agente ha scritto tutti e tre nel nostro Worker, la piccola funzione che gira davanti alle tue pagine quando le visiti. Poi li ha testati contro un finto servizio di mailing, mai quello reale, e ogni richiesta è stata rifiutata esattamente dove doveva. Se invii dal sito sbagliato vieni rifiutato. Anche la tua sesta richiesta in un minuto viene rifiutata, e senza consenso vieni respinto.

Il limite è che uno script può falsificare il timbro Origin, e il rate limit conta per posizione, quindi la vera soluzione è la doppia conferma via email.

La sesta e ultima regola è dimostrare la correzione, perché un muro di spunte verdi è proprio il momento in cui smetti di guardare. Uno sviluppatore che ha provato REA su un'app desktop ha scritto su HackerNoon che aveva mancato punti di ingresso che l'app aveva davvero.

Quindi rilancia gli stessi passaggi di REA sulla build corretta, verifica a mano ogni correzione dal terminale e solo dopo apri la pull request.

Sulla build corretta, la richiesta che prima passava dal nostro modulo di iscrizione viene rifiutata. Le nostre chiavi del server erano sparite da ogni file pubblicato, gli header di sicurezza c'erano e i test del Worker sono passati da falliti a superati. Il gate sui nostri pack gratuiti era ancora aperto, ed è quello che abbiamo deciso, e il report lo dice accanto a ogni riga.

L'agente ha poi aperto la pull request. I report ci sono solo perché li abbiamo chiesti nel prompt. La checklist di test che Kosuke costruisce è rimasta dentro la sessione, senza nulla pubblicato sulla pull request stessa. Se il tuo reviewer legge solo GitHub, metti tu nella pull request i report prima e dopo.

Abbiamo poi portato la stessa modifica nel nostro codice, e andrà online con il prossimo deploy del nostro sito.

L'intera esecuzione era REA puntato sul nostro sito live da una sandbox usa e getta, ogni risultato smistato, le perdite reali corrette, un nuovo audit e il tutto spedito come pull request. Il risultato che ha giustificato tutto era il primo: qualsiasi sito poteva riempire il nostro modulo di iscrizione con l'indirizzo di chiunque.

Lancia questo audit prima di pubblicare qualsiasi cosa con un modulo pubblico o un servizio a pagamento dietro, e di nuovo ogni volta che cambi ciò che viene pubblicato. Non lanciarlo su software che non possiedi, perché il disclaimer di REA lo limita al software che possiedi o che sei autorizzato a esaminare. E non sostituisce mai la lettura del codice del tuo server, perché è esattamente lì che stanno le incognite.

Se tieni una sola regola, tieni questa: lancialo su te stesso, in una scatola, e correggi solo ciò che hai smistato.

Il prompt esatto, la tabella di triage e la correzione del Worker che abbiamo spedito sono nel kit gratuito di questo video.