AIDiveIntro: apúntalo primero a ti mismo
Apunta REA a tu propia app antes de que otro la desmonte. Lo ejecutamos sobre nuestra web publicada desde un sandbox en la nube desechable, arreglamos lo que encontró y enviamos el pull request.
REA es la skill de ingeniería inversa que toda una ola de vídeos apuntó al software de otros. En nuestra web necesitó menos de trece minutos y ni una sola petición de escritura para demostrar que cualquier sitio web podía llenar nuestra lista de correo. También encontró el tope diario de nuestro bot de comentarios, escrito dentro del JavaScript que descarga quien visita nuestra web. Tras el arreglo, la petición que antes se colaba es rechazada.
El resultado son seis reglas para ejecutar la misma auditoría sobre tu app: el sandbox desechable, el objetivo exacto, ordenar los hallazgos, la config dentro de tu bundle, los frenos en los endpoints y la prueba del arreglo.
Qué es REA y cómo se instala
REA significa Reverse Engineer Anything: un conjunto de herramientas que permite a Claude Code desmontar la app que publicas. Hacer ingeniería inversa es deducir cómo está construido algo a partir del producto terminado, como un mecánico que lee un coche sin los planos de fábrica.
En vez de leer tu código fuente, REA lee el bundle, que es el JavaScript que tu web envía de verdad a cada visitante. A partir de ese bundle lista las rutas, los endpoints que llaman tus páginas y todo lo que dejaste ahí por error. No puede devolverte el código fuente, porque solo te da evidencias, y su propia documentación dice que tampoco es un sandbox.
Para instalarlo:
- Instala REA desde su paquete oficial y fija la versión, porque sacó seis versiones en una semana.
- Ejecuta su setup para Claude Code.
- Activa el perfil compacto, ya que carga bastante más de cien herramientas en tu sesión.
- Instala solo desde el repositorio oficial, porque ya circulan copias falsas con malware dentro.
Cuando ejecutamos la instalación en nuestro sandbox, el agente comprobó primero que el paquete apuntaba al repositorio oficial antes de tocar nada. Después el setup instaló la skill pero ningún servidor de herramientas, así que Claude Code usó simplemente las versiones en línea de comandos de las mismas herramientas. Si tus herramientas no aparecen tras el setup, no hace falta reiniciar nada: llama a los mismos pasos desde la terminal.
Regla 1: ejecútalo donde no pueda hacer daño
La primera regla trata de dónde lo ejecutas. Vas a dejar que un agente maneje un navegador y ejecute herramientas descargadas contra tu app en producción. En tu portátil, ese agente está al lado de tus claves, de tus otros proyectos y de todas las cuentas en las que tienes sesión abierta. Las propias notas de seguridad de REA lo dicen sin rodeos: esto no es un sandbox.
Un sandbox es una máquina desechable: lo que salga mal se queda dentro y la borras. Abre un sandbox desechable sobre tu repositorio y haz toda la auditoría ahí, nunca en tu propia máquina.
Nosotros usamos Kosuke, que ejecuta Claude Code con tu propia suscripción dentro de una máquina en la nube desechable. Eliges tu repositorio, le dices al agente de despliegue cómo arranca tu app y te da una preview, un enlace donde aparece tu app en ejecución. Cada chat tiene además su propia rama, es decir, su propia copia del código, y termina con un pull request. Cuando importamos nuestra web, el agente instaló el gestor de paquetes y un navegador headless, midió la memoria y eligió él solo el tamaño de la máquina. Unos minutos después nuestra web real corría junto al chat, en una rama que nadie más toca.
Una trampa de una prueba anterior: una app Next.js recién creada aparecía en la preview, pero nada en la página respondía. El arreglo es una línea en tu config de Next que permite la dirección de la preview, y la página cobra vida.
El límite es que es el mismo Claude Code con una caja alrededor, así que una máquina virtual local o un contenedor hacen el mismo trabajo. Lo que importa es la caja, no la marca.
Divulgación: Kosuke nos dio acceso gratis a su plan superior. Escribe el código AIDIVE2026 en el campo «Promo code» justo después de registrarte y tendrás treinta dólares de crédito en vez de los diez habituales.
Regla 2: una URL exacta, toda escritura bloqueada
La segunda regla es lo que le dices realmente a REA. Si solo dices «audita mi app», la skill de REA se detiene y pregunta qué app.
REA tampoco abre nunca un navegador por sí mismo, así que lanzas uno con un puerto de depuración, una puerta que permite a una herramienta ver todo lo que hace la página. Prepáralo en este orden:
- Mantén el puerto de depuración en el loopback, la dirección a la que solo llega tu propia máquina, y dale al navegador un perfil nuevo.
- Bloquea toda petición de escritura antes de que cargue ninguna página, para que la auditoría pueda leer tu web pero no pueda enviar un formulario ni cambiar nada.
- Solo entonces dale a REA las páginas exactas que quieres que lea.
En nuestro prompt nombramos dos páginas de nuestro club gratis y escribimos una regla con palabras llanas: nunca envíes una escritura a la web publicada. Importaba, porque el formulario de esas páginas alimenta una lista de correo real con personas reales. El agente se tomó la regla en serio y escribió su propio pequeño guardián que dejaba pasar las lecturas y detenía todo lo demás. Durante la auditoría, ese guardián frenó seis intentos del script de analítica, y ni una sola petición llegó nunca a nuestro formulario de registro.
Luego REA hizo su parte: inspeccionar cada página, leer cada bundle, tomar capturas de pantalla y exportar los scripts fuera del repositorio.
El límite es que REA solo ve lo que carga mientras está conectado, así que cualquier cosa que ocurrió antes queda como una incógnita en el informe. Aun así, ya tienes un informe sobre tu propia app en producción, escrito sin tocar ni un solo dato suyo.
Regla 3: ordena cada hallazgo antes de arreglar uno
La tercera regla es ordenar antes de arreglar. Un informe así está lleno de líneas alarmantes y querrás arreglarlas todas a la vez.
La skill de REA quiere que cada conclusión esté marcada como observación, inferencia o incógnita, con un ID de evidencia. Es lo que vio, lo que supuso y lo que no pudo ver, y el ID de evidencia es un recibo que puedes comprobar. Ordena primero cada hallazgo así, usando solo la vista de un extraño, y haz commit de esa versión antes de abrir ni un archivo fuente. Después lee tu código y marca cada línea como fuga real, por diseño o falso positivo.
Nuestro informe tenía quince hallazgos:
| Hallazgo | Lo que vio REA | Nuestro veredicto |
|---|---|---|
| Endpoint de registro | Sin límite y sin comprobar qué sitio llamaba, así que cualquier web podía hacer que el navegador de un visitante suscribiera cualquier dirección a nuestra lista | Fuga real, la peor |
| Barrera de email en los packs gratis | El pack entero ya está en la página que cargas; una línea en la consola del navegador quita la barrera, o el modo lectura muestra el texto | Por diseño |
| Source maps, claves, cookies | Ninguno en los bundles, ninguna cookie en ningún sitio | Buenas noticias |
La barrera es por diseño porque los packs son gratis a propósito, y nuestro propio código dice que un formulario roto nunca debe ocultar una página gratis.
El límite es la columna de incógnitas. REA no puede ver lo que hace tu servidor, así que esas líneas las resuelves leyendo tu código de servidor.
Regla 4: tu bundle envía tu config
La cuarta regla trata de lo que lleva tu bundle, porque un solo archivo de ajustes compartido puede viajar a cada visitante sin que lo notes.
Así ocurre. Importas tu config en un helper, y dos pequeños componentes interactivos usan ese helper. El bundler, la herramienta que empaqueta tu código en los archivos que descarga el navegador, no sabe qué claves necesitan, así que las envía todas.
Eso es exactamente lo que REA encontró en nuestro JavaScript. Toda la config de nuestra web estaba en un solo archivo, con el ID de nuestra lista de correo, nuestras carpetas de build y los límites del bot que responde a los comentarios de nuestros vídeos. Incluso decía cuántas respuestas envía ese bot al día, cien, y cuántos errores activan su interruptor de seguridad. Los dos componentes que lo importaban solo leían el nombre del sitio y la lista de idiomas.
La regla: busca en tu JavaScript publicado tus propias claves de config, y da a los componentes de cliente solo los campos que leen. En nuestro sandbox, el agente dividió la config en una versión diminuta para el navegador con solo esos campos, y el resto se quedó en el servidor. También añadió un paso de build que falla si una clave de servidor vuelve a aparecer en un archivo publicado, para que no puedas retroceder.
Nada de esto era una contraseña, pero todo lo que hay en ese archivo es público, así que tus secretos solo viven en variables de servidor.
Regla 5: todo endpoint abierto necesita un freno
La quinta regla arregló nuestra fuga real, y se aplica siempre que tengas un formulario público que llama a un servicio de pago: tu lista de email, tu modelo de IA o tu pasarela de SMS. Lo llamas mediante una pequeña función de servidor que escribiste en una tarde. La nuestra recibía un email y lo pasaba directo a la lista de correo, y cualquier otra web podía hacer que el navegador de un visitante se lo enviara.
La propia lista de comprobación del mundo de la seguridad lo dice claro: tu control de acceso solo funciona en código que el atacante no puede cambiar, es decir, tu servidor. Así que pon frenos en cada endpoint de ese tipo:
- Comprobación de Origin. La cabecera Origin es el sello que pone un navegador en una petición para indicar qué sitio la envió, de modo que un formulario de otra web es rechazado.
- Rate limit. Un tope al número de peticiones que un visitante puede enviar en una ventana corta.
- Consentimiento comprobado en el servidor. La casilla que marcas viaja de verdad con la petición.
En nuestro sandbox, el agente los escribió todos en nuestro Worker, la pequeña función que se ejecuta delante de tus páginas cuando las visitas. Luego los probó contra un servicio de correo falso, nunca el real, y cada petición fue rechazada exactamente donde debía. Si envías desde la web equivocada, te rechazan. Tu sexta petición en un minuto también es rechazada, y sin consentimiento quedas rechazado.
El límite es que un script puede falsificar el sello Origin, y el rate limit cuenta por ubicación, así que el arreglo de verdad para eso es la doble confirmación por email.
Regla 6: vuélvelo a ejecutar, comprueba a mano, envía el PR
La sexta y última regla es demostrar el arreglo, porque un muro de checks verdes es justo cuando dejas de mirar. Un desarrollador que probó REA en una app de escritorio escribió en HackerNoon que se le escaparon puntos de entrada que la app sí tenía.
Así que ejecuta de nuevo los mismos pasos de REA sobre el build arreglado, comprueba cada arreglo a mano desde la terminal y solo entonces abre el pull request.
En el build arreglado, la petición que antes se colaba por nuestro formulario de registro es rechazada. Nuestras claves de servidor habían desaparecido de todos los archivos publicados, las cabeceras de seguridad estaban ahí y los tests del Worker pasaron de fallar a pasar. La barrera de nuestros packs gratis seguía abierta, que es lo que decidimos, y el informe lo dice junto a cada línea.
Después el agente abrió el pull request. Los informes están en él solo porque los pedimos en el prompt. La lista de pruebas que construye Kosuke se quedó dentro de la sesión, sin publicar nada en el propio pull request. Si tu revisor solo lee GitHub, pon tú mismo los informes de antes y después en el pull request.
Luego llevamos el mismo cambio a nuestro propio código, y saldrá en producción con el próximo despliegue de nuestra web.
Veredicto: cuándo apuntar REA a ti mismo
Toda la operación fue REA apuntado a nuestra propia web publicada desde un sandbox desechable, cada hallazgo ordenado, las fugas reales arregladas, otra auditoría y un pull request. El hallazgo que lo justificaba todo fue el primero: cualquier web podía llenar nuestro formulario de registro con la dirección de cualquiera.
Haz esta auditoría antes de lanzar cualquier cosa con un formulario público o un servicio de pago detrás, y de nuevo cada vez que cambies lo que publicas. No la hagas sobre software que no es tuyo, porque el descargo de REA lo limita al software que posees o estás autorizado a examinar. Y nunca sustituye leer tu código de servidor, porque ahí es exactamente donde viven las incógnitas.
Si te quedas con una sola regla, quédate con esta: ejecútalo sobre ti mismo, dentro de una caja, y arregla solo lo que hayas ordenado.
El prompt exacto, la tabla de triaje y el arreglo del Worker que enviamos están en el kit gratis de este vídeo.
