Ele achou uma porta aberta no meu próprio site. Veja a correção

Aponte o REA para o seu app antes que outra pessoa o desmonte. Nós o apontamos para o nosso próprio site no ar, a partir de um sandbox descartável na nuvem, corrigimos o que ele achou e enviamos o pull request.

O REA é a skill de engenharia reversa que uma onda de vídeos apontou para o software dos outros. No nosso site, ele precisou de menos de treze minutos e de nenhuma requisição de escrita para mostrar que qualquer site podia encher a nossa lista de e-mails. Ele também achou o limite diário do nosso bot de comentários dentro do JavaScript que você baixa do nosso site. Depois da correção, a requisição que antes passava é recusada.

O resultado são seis regras para rodar a mesma auditoria no seu app: o sandbox descartável, a URL exata, a classificação dos achados, a config no seu bundle, os freios dos endpoints e a prova da correção.

REA quer dizer Reverse Engineer Anything: um conjunto de ferramentas que deixa o Claude Code desmontar o app que você publica. Engenharia reversa é descobrir como algo foi construído a partir da coisa pronta, como um mecânico que lê um carro sem ter os desenhos da fábrica.

Em vez de ler o seu código-fonte, o REA lê o bundle, que é o JavaScript que o seu site realmente envia a cada visitante. Desse bundle ele lista as rotas, os endpoints que as suas páginas chamam e qualquer coisa que você deixou ali por engano. Ele não devolve o código-fonte, porque você só recebe evidências, e a própria documentação dele diz que ele também não é um sandbox.

Para instalar:

1. Instale o REA pelo pacote oficial e fixe a versão, porque ele lançou seis releases em uma semana.
2. Rode o setup dele para o Claude Code.
3. Ative o perfil compact, já que ele carrega bem mais de cem ferramentas na sua sessão.
4. Instale só pelo repositório oficial, porque já circulam cópias falsas com malware dentro.

Quando rodamos a instalação no nosso sandbox, o agente primeiro conferiu que o pacote apontava para o repositório oficial antes de mexer em qualquer coisa. O setup instalou a skill, mas nenhum servidor de ferramentas, então o Claude Code usou as versões de linha de comando das mesmas ferramentas do REA. Se as ferramentas não aparecerem depois do setup, você não precisa reiniciar nada: chame os mesmos passos pelo terminal.

A primeira regra é sobre onde você roda. Você vai deixar um agente controlar um navegador e executar ferramentas baixadas contra o seu app em produção. No seu notebook, esse agente fica ao lado das suas chaves, dos seus outros projetos e de todas as contas em que você está logado. As próprias notas de segurança do REA dizem sem rodeios: isto não é um sandbox.

Um sandbox é uma máquina descartável: se algo der errado, fica lá dentro e você a apaga. Abra um sandbox descartável no seu repositório e rode a auditoria inteira nele, nunca na sua própria máquina.

Usamos o Kosuke, que roda o Claude Code na sua própria assinatura dentro de uma máquina descartável na nuvem. Você escolhe o repositório, diz ao agente de deploy como o app sobe e ele entrega um preview, um link onde o seu app em execução aparece. Cada chat também ganha a sua própria branch, ou seja, a sua própria cópia do código, e termina com um pull request. Quando importamos o nosso site, o agente instalou o gerenciador de pacotes e um navegador headless, mediu a memória e escolheu sozinho o tamanho da máquina. Poucos minutos depois, o nosso site de verdade estava rodando ao lado do chat, numa branch em que ninguém mais mexe.

Uma armadilha de um teste anterior: um app Next.js novo aparecia no preview, mas nada na página respondia. A correção é uma linha na config do Next que libera o endereço do preview, e a página ganha vida.

O limite é que isto é o mesmo Claude Code com uma caixa em volta, então uma máquina virtual local ou um contêiner faz o mesmo trabalho. O que importa é a caixa, não a marca.

Aviso: o Kosuke nos deu acesso grátis ao plano mais alto. Digite o código AIDIVE2026 no campo "Promo code" logo depois do cadastro e você ganha trinta dólares de créditos em vez dos dez de sempre.

A segunda regra é o que você de fato diz ao REA. Se você só disser "audite meu app", a skill do REA para e pergunta qual app.

O REA também nunca abre um navegador sozinho, então você inicia um com uma porta de depuração, uma porta que deixa uma ferramenta observar tudo o que a página faz. Monte nesta ordem:

1. Mantenha a porta de depuração no loopback, o endereço que só a sua máquina alcança, e dê ao navegador um perfil novo.
2. Bloqueie toda requisição de escrita antes de qualquer página carregar, para que a auditoria possa ler o seu site, mas não envie um formulário nem mude nada.
3. Só então dê ao REA as páginas exatas que você quer que ele leia.

No nosso prompt, citamos duas páginas do nosso clube gratuito e escrevemos uma regra em palavras simples: nunca enviar uma escrita ao site no ar. Isso importava, porque o formulário dessas páginas alimenta uma lista de e-mails real, com gente de verdade. O agente levou a regra a sério e escreveu a sua própria guarda, pequena, que deixava as leituras passarem e barrava todo o resto. Durante a auditoria, essa guarda barrou seis tentativas do script de analytics, e nenhuma requisição chegou ao nosso formulário de inscrição.

Aí o REA fez a parte dele: inspecionou cada página, leu cada bundle, tirou screenshots e exportou os scripts para fora do repositório.

O limite é que o REA só observa o que carrega enquanto está conectado, então tudo o que aconteceu antes continua como desconhecido no relatório. Mesmo assim, você passa a ter um relatório do seu app no ar, escrito sem tocar em nenhum dado dele.

A terceira regra é classificar antes de corrigir. Um relatório assim vem cheio de linhas alarmantes e você vai querer corrigir tudo de uma vez.

A skill do REA quer cada conclusão marcada como observação, inferência ou desconhecido, com um ID de evidência. Isso é o que ele viu, o que ele supôs e o que ele não conseguiu ver, e o ID de evidência é um recibo que você pode conferir. Classifique cada achado assim primeiro, usando só a visão de quem está de fora, e faça o commit dessa versão antes de abrir qualquer arquivo de código. Depois leia o seu código e marque cada linha como vazamento real, como intencional ou como falso positivo.

O nosso relatório teve quinze achados:

Achado	O que o REA viu	Nosso veredito
Endpoint de inscrição	Sem limite e sem checagem de qual site estava chamando, então qualquer site podia fazer o navegador de um visitante inscrever qualquer e-mail na nossa lista	Vazamento real, o pior
Trava de e-mail nos packs gratuitos	O pack inteiro já está na página que você carrega; uma linha no console do navegador remove a trava, ou o modo leitura mostra o texto	Intencional
Source maps, chaves, cookies	Nenhum nos bundles, nenhum cookie em lugar nenhum	Boa notícia

A trava é intencional porque os packs são gratuitos de propósito, e o nosso próprio código diz que um formulário quebrado nunca deve esconder uma página gratuita.

O limite é a coluna do desconhecido. O REA não enxerga o que o seu servidor faz, então você resolve essas linhas lendo o código do seu servidor.

A quarta regra é sobre o que o seu bundle carrega, porque um arquivo de configurações compartilhado pode viajar até cada visitante sem você perceber.

Veja como acontece. Você importa a sua config em um helper, e dois componentes interativos pequenos usam esse helper. O bundler, a ferramenta que empacota o seu código nos arquivos que o navegador baixa, não sabe quais chaves eles precisam, então envia todas.

Foi exatamente isso que o REA achou no nosso JavaScript. A config inteira do site estava num único arquivo, com o ID da nossa lista de e-mails, as nossas pastas de build e os limites do bot que responde aos comentários dos nossos vídeos. Ela até dizia quantas respostas o bot envia por dia, cem, e quantos erros acionam o interruptor de segurança. Os dois componentes que a importavam só liam o nome do site e a lista de idiomas.

A regra: procure no seu JavaScript publicado as suas próprias chaves de config e passe aos componentes de cliente só os campos que eles leem. No nosso sandbox, o agente dividiu a config numa versão minúscula para o navegador, só com esses campos, e o resto ficou no servidor. Ele também adicionou uma etapa de build que falha se uma chave de servidor voltar a aparecer num arquivo publicado, para você não regredir.

Nada disso era uma senha, mas tudo o que está nesse arquivo é público, então os seus segredos só vivem em variáveis de servidor.

A quinta regra corrigiu o nosso vazamento de verdade, e vale sempre que você tem um formulário público que chama um serviço pago: a sua lista de e-mails, o seu modelo de IA ou o seu gateway de SMS. Você o chama por uma função de servidor minúscula que escreveu numa tarde. A nossa recebia um e-mail e o repassava direto para a lista, e qualquer outro site podia fazer o navegador de um visitante enviar isso.

O checklist do próprio mundo da segurança diz sem rodeios: o seu controle de acesso só funciona em código que o atacante não consegue alterar, ou seja, o seu servidor. Então ponha freios em todo endpoint assim:

• Checagem de Origin. O cabeçalho Origin é o carimbo que o navegador põe numa requisição para dizer qual site a enviou, então um formulário em outro site é recusado.
• Rate limit. Um teto de quantas requisições um visitante pode enviar numa janela curta.
• Consentimento checado no servidor. A caixa que você marca viaja de fato com a requisição.

No nosso sandbox, o agente escreveu tudo isso no nosso Worker, a pequena função que roda na frente das suas páginas quando você as visita. Depois testou contra um serviço de e-mail falso, nunca o de verdade, e cada requisição foi recusada exatamente onde devia. Enviar do site errado é recusado. A sua sexta requisição em um minuto também é recusada, e sem consentimento você é rejeitado.

O limite é que um script pode falsificar o carimbo de Origin, e o rate limit conta por localização, então a correção de verdade para isso é a dupla confirmação por e-mail.

A sexta e última regra é provar a correção, porque um muro de checks verdes é justamente quando você para de olhar. Um desenvolvedor que testou o REA num app desktop escreveu no HackerNoon que ele deixou passar pontos de entrada que o app realmente tinha.

Então rode de novo os mesmos passos do REA no build corrigido, confira cada correção à mão pelo terminal e só então abra o pull request.

No build corrigido, a requisição que antes passava pelo nosso formulário de inscrição é recusada. As nossas chaves de servidor sumiram de todos os arquivos publicados, os cabeçalhos de segurança estavam lá e os testes do Worker passaram de falhando para passando. A trava dos nossos packs gratuitos continuava aberta, que é o que decidimos, e o relatório diz isso ao lado de cada linha.

O agente então abriu o pull request. Os relatórios estão nele só porque pedimos no prompt. O checklist de testes que o Kosuke monta ficou dentro da sessão, sem nada publicado no próprio pull request. Se o seu revisor só lê o GitHub, ponha você mesmo os relatórios de antes e depois no pull request.

Depois trouxemos a mesma mudança para o nosso próprio código, e ela vai ao ar no próximo deploy do nosso site.

A execução inteira foi o REA apontado para o nosso próprio site no ar, a partir de um sandbox descartável, com cada achado classificado, os vazamentos reais corrigidos, auditados de novo e enviados como pull request. O achado que justificou tudo foi o primeiro: qualquer site podia encher o nosso formulário de inscrição com o e-mail de qualquer pessoa.

Rode esta auditoria antes de lançar qualquer coisa com um formulário público ou um serviço pago por trás, e de novo sempre que você mudar o que é publicado. Não a rode em software que não é seu, porque o próprio aviso do REA o limita a software que você possui ou tem autorização para examinar. E ela nunca substitui a leitura do código do seu servidor, porque é exatamente ali que moram os desconhecidos.

Se você guardar uma só regra, guarde esta: rode em você mesmo, numa caixa, e corrija só o que você classificou.

O prompt exato, a tabela de triagem e a correção do Worker que enviamos estão no kit gratuito deste vídeo.