Hoy lanzamos tres cosas:
- AfterPack, un ofuscador de JavaScript moderno para la era de la IA. Convierte tu build de producción en un programa distinto cada vez: una forma nueva en cada build, y en cada petición dentro de un Cloudflare Worker.
- Un escáner de sitios renovado que encuentra qué es legible en el código de cualquier sitio web: source maps públicos, lógica legible y credenciales filtradas.
- Un playground online para probar AfterPack con tu propio código, directamente en el navegador.
AfterPack (afterpack.dev), el ofuscador de JavaScript, funciona con cualquier framework. El CLI y los plugins son open source, el motor local es gratuito, y los builds en la nube de Pro empiezan en 49 $ al mes. Empieza con npx afterpack@latest después de un build, o pídele a tu agente de código que lo añada.
Conoce AfterPack: una herramienta de build gratuita que hace que tu código publicado sea ilegible para escáneres y personas, y un blanco móvil para la IA. Cada build publica código completamente distinto, así que un script escrito para parchear una release —un cheat, un userscript, un bypass— no encaja en la siguiente. Una herramienta escrita contra tu código debería dejar de funcionar en tu siguiente release, y ahora, dentro de tu propio Cloudflare Worker, puede dejar de funcionar en tu próxima petición.
¿Por qué ofuscar JavaScript ahora que la IA puede leerlo?
Porque todo lo que la IA puede leer, también puede reescribirlo y reempaquetarlo. Apunta un agente de código a tu bundle, y unos minutos después alguien tiene tus reglas de precios, tu verificación de paywall o tu lógica antibot como código fuente limpio y editable, junto con un script que los parchea o los evade. Antes era trabajo de especialistas; ahora es una instrucción. Y el parche sigue funcionando mientras tu código mantenga su forma. La minificación nunca escondió ese código: la "filtración" de Claude Code era un bundle legible publicado en npm desde su lanzamiento. Qué sigue revelando un bundle minificado, y cómo comprobarlo en tu propio sitio, lo explico en qué pueden ver los usuarios en tu JavaScript y cómo protegerlo.
En mayo de 2026 le di las demos insignia de dos ofuscadores populares a Claude Code con una sola instrucción de cuatro párrafos. Claude Opus 4.6 devolvió código fuente limpio en 10 minutos; Claude Opus 4.7 tardó 20. Eran demos pequeñas, no aplicaciones enteras, y esos modelos ya son una generación anterior a los de hoy.
Tus reglas de precios, comprobaciones de licencia, heurísticas antifraude y funcionalidades sin anunciar siempre han estado en el bundle. Lo que ha cambiado es quién puede leerlas, y a qué velocidad. Lo que todavía controlas es cuánto de ese trabajo se traslada a tu siguiente release.
¿Se puede revertir el JavaScript ofuscado?
Sí. Con tiempo suficiente, la salida de cualquier ofuscador se puede revertir, la de AfterPack incluida. Lo que cambia AfterPack es el traslado: cuánto del trabajo de revertir una release sigue sirviendo para la siguiente. En nuestra propia medición (septiembre de 2026, seis semillas × cinco muestras), menos del 6 % de lo que un desofuscador recuperó de un build seguía resolviéndose en el siguiente (cómo lo medimos).
La lógica que alguien ya leyó también se queda leída: si descubrió tu regla de descuentos una vez, un build nuevo no se la va a borrar de la cabeza.
Lo que sí puede caducar es la herramienta construida sobre esa lectura. Un script que elimina una comprobación de licencia, un parcheador para un muro de pago, un extractor que saca tus reglas de puntuación de cada release: cada uno está escrito contra la estructura de un build concreto. El ofuscador open source más popular genera formas de salida fijas, y los desofuscadores públicos gratuitos traen reconocedores codificados a mano para ellas, así que una herramienta escrita una vez sigue funcionando en todos los builds futuros.
AfterPack parte de una semilla aleatoria nueva en cada build. Los nombres de los identificadores, los strings codificados, la firma del decodificador, la numeración de estados y las constantes enmascaradas salen todos distintos, así que los detalles que una herramienta deja fijos cambian cada vez. Ejecuta el motor dentro de un Worker y la ventana se reduce de una release a una sola petición.
¿Qué trae AfterPack?
Un CLI, plugins para los bundlers que ya usas, un build en WebAssembly para Workers, builds en la nube con Pro, un informe de lo que protegió cada build y un escáner de sitios gratuito.
| Dato | AfterPack |
|---|---|
| Qué es | Un ofuscador de JavaScript para builds de producción: reescribe lo que produce tu bundler, no tus archivos fuente |
| Motor | Rust, ejecutado en local por el CLI y los plugins, o como WebAssembly (@afterpack/wasm) dentro de tu propio Worker |
| Salida | Distinta en cada build por defecto en el CLI y los plugins; fija una semilla solo cuando necesites bytes idénticos |
| Licencia | CLI y plugins bajo Apache-2.0; el motor es de uso gratuito bajo la AfterPack Engine License |
| Precio | Motor local gratuito; Pro desde 49 $ al mes (planes) |
| Para empezar | npx afterpack@latest después de tu build, o un plugin de framework |
Lo que la tabla no muestra:
- Plugins de framework para Next.js, Vite, webpack, Astro, Nuxt, SvelteKit, Svelte, Vue, Angular, Parcel, esbuild, Rollup y Electron. Tu build de producción habitual genera la salida ofuscada.
- Pro: pasa una clave y la misma llamada se ejecuta en la nube de AfterPack, con directivas que dirigen una protección más fuerte al código que importa. Si la clave o la nube no están disponibles, el build falla en lugar de publicar menos protección sin avisar.
- El Protection Map: un informe HTML de tu código fuente original con cada token coloreado según cuánta transformación ha recibido. Se genera cuando tu build emite un source map; los plugins pueden activarlo por ti.
- El escáner de seguridad gratuito, también disponible como
npx afterpack audit <url>.
¿Cómo es la salida ofuscada de AfterPack?
Los identificadores desaparecen y los string literals quedan codificados tras un decodificador en tiempo de ejecución; cuánto más ocurra depende del preset. light (el predeterminado) codifica strings y reescribe la sintaxis, sin añadir capas estructurales —la base adecuada para la mayoría de proyectos. medium hace el código de producción notablemente más difícil de seguir; hard es para el código que importa, como precios, control de acceso y comprobaciones de licencia; extreme fija la complejidad más alta de los presets, mejor dirigida a una función o un archivo que a todo un bundle.
Una función de 139 bytes, antes:
| 1 | export function discount(plan, seats) { |
| 2 | if (plan === "team" && seats >= 10) return 0.2; |
| 3 | if (plan === "team") return 0.1; |
| 4 | return 0; |
| 5 | } |
Y después de una ejecución de npx afterpack@latest con el preset por defecto light (27 de septiembre de 2026):
| 1 | export function discount(N, O) { |
| 2 | if (N === Jr("T|P4") && O >= 10) return 0.2; |
| 3 | if (N === Jr("T|P4")) return 0.1; |
| 4 | return 0; |
| 5 | } |
"team" ha desaparecido, sustituido por un texto cifrado y una llamada al decodificador; ejecútalo otra vez y los nombres, el texto cifrado y la firma del decodificador salen todos distintos. En light, números como 10, 0.2 y 0.1 se quedan legibles; medium y los superiores también enmascaran constantes enteras como ese 10. El decodificador en sí supone un sobrecoste, así que un archivo tan pequeño como este sale proporcionalmente más grande de lo que saldría un bundle real: en un bundle real, light sale entre 1,9 y 2,4 veces el tamaño de la entrada, con gzip (presets).
Pega tu propia función en el playground para ver qué le hace cada preset, sin instalar nada y sin cuenta.
Prueba AfterPack ahora mismo
- Pega código: el playground ofusca lo que pegues, directamente en el navegador, sin instalar nada.
- Escanea tu sitio: el escáner de seguridad muestra lo que tu JavaScript de producción ya expone.
- Un prompt: dáselo a un agente de código —
Add AfterPack to this project: read afterpack.dev/llms.txt, follow the quickstart for my framework, then run a production build and show me the Protection Map. - Un comando: ejecuta
npx afterpack@latestdespués de tu próximo build.
Ofusca JavaScript en cada petición en un Cloudflare Worker
@afterpack/wasm ejecuta el motor como WebAssembly dentro de tu propio Worker, así que una semilla nueva en cada llamada ofusca cada respuesta de forma distinta:
| 1 | import { obfuscate } from "@afterpack/wasm"; |
| 2 | |
| 3 | export default { |
| 4 | async fetch(request) { |
| 5 | const upstream = await fetch("https://example.com/app.js"); // your origin's bundle |
| 6 | if (!upstream.ok) return upstream; |
| 7 | const source = await upstream.text(); |
| 8 | const result = await obfuscate( |
| 9 | { path: "app.js", source }, |
| 10 | { preset: "hard", seed: crypto.randomUUID() }, |
| 11 | ); |
| 12 | return new Response(result.bytes, { |
| 13 | headers: { "content-type": "application/javascript" }, |
| 14 | }); |
| 15 | }, |
| 16 | }; |
Si ejecutamos ese handler en Node en un Apple M2 Max (27 de septiembre de 2026), sirviendo el archivo discount desde un origen local, cuatro peticiones devuelven cuatro salidas distintas, cada una con los descuentos correctos. Con el módulo ya caliente, cada ofuscación tarda menos de 4 ms; la primera llamada, que instancia el motor, tarda unos 40 ms. Eso es con una entrada de 139 bytes; un bundle real cuesta mucha más CPU, y se paga en cada respuesta. La guía de Workers cubre los límites de los planes y cuándo compensa más cachear una forma por ventana de rotación.
La configuración completa, con la config de wrangler, una forma cacheada por ventana de tiempo y salida real de curl, está en el tutorial sobre cómo ofuscar JavaScript en cada petición con Cloudflare Workers.
Cómo ofuscar un build de Next.js, Vite, webpack o cualquier otro
Ejecuta el CLI después de tu build, o instala el plugin de tu bundler para que cada build de producción salga ofuscado. El CLI no necesita configuración; ejecuta esto en la raíz del proyecto después del build:
| npx afterpack@latest |
Encuentra la salida de tu build (dist/, .next/, .output/, build/ u out/), la reescribe en su sitio y guarda una copia de seguridad; npx afterpack@latest restore deshace la ejecución.
Para que la ofuscación forme parte del propio build, instala el plugin de tu bundler:
| npm install -D @afterpack/next # or @afterpack/vite, @afterpack/webpack |
Cada plugin requiere un pequeño cambio de configuración, como envolver tu configuración de Next.js en withAfterpack(config); frameworks lo muestra para cada bundler compatible, de Astro a Parcel. Para ver qué expone hoy tu sitio en producción, pásalo antes por el escáner.
¿Cuáles son los límites de AfterPack?
AfterPack encarece leer tu código y reutilizar herramientas contra él; no puede ocultar valores a quien instrumente el programa en ejecución, así que los secretos y todo lo que concede acceso deben estar en tu servidor. Lo que sí te da llega con el build que ya ejecutas: un objetivo nuevo en cada release, sin ningún paso extra que recordar.
¿Qué viene después para AfterPack?
Lo siguiente es la ofuscación de red: network transport cloaking hará pasar tus peticiones y respuestas de API por un códec que cambia con cada build. La ofuscación entre módulos unirá la lógica a través de los límites de módulo, y AfterPack on Workers for Platforms servirá una forma nueva en cada petición sin nada que instalar. Después de JavaScript, vamos a por HTML y CSS.
Preguntas frecuentes sobre AfterPack
¿AfterPack es gratis?
Sí. El CLI, los plugins de framework y el motor local son gratuitos, y tu código fuente nunca sale de tu máquina. Pro añade builds en la nube y directivas por región desde 49 $ al mes, y un workspace Free registrado recibe 10 MB de builds Pro al mes. La tabla completa está en planes y niveles.
¿AfterPack es open source?
El CLI y los plugins de framework sí, bajo Apache-2.0, en GitHub. El motor que ejecutan es de uso gratuito bajo la AfterPack Engine License.
¿La ofuscación ralentiza mi código?
Un poco, y más cuanto más fuerte es el preset. El predeterminado es light. Sube el preset para todo el proyecto, o usa una directiva de Pro para aplicar hard o extreme solo a las funciones que lo necesitan.
¿En qué se diferencia AfterPack de otros ofuscadores de JavaScript?
Trabaja sobre tu build de producción mediante un plugin para el bundler que ya usas, y por defecto cada build produce una salida distinta, así que un desofuscador escrito para una release deja de funcionar, en su mayor parte, en la siguiente. El tiempo de build, el tamaño de la salida y lo que se traslada de un build a otro, medidos lado a lado con otros ofuscadores, están en la página de comparación.
¿La ofuscación oculta las claves de API?
No. Todo lo que usa tu código en ejecución lo puede observar quien lo ejecute en un navegador que controla, así que mantén las claves de API y demás secretos en tu servidor. La codificación sí deja una clave fuera del alcance de un grep y de los escáneres automáticos de secretos, lo que da tiempo para rotar una que se publicó por accidente (buenas prácticas).
¿Encontraste un bug, o quieres un bundler que todavía no cubrimos? Abre un issue en GitHub con tu bundler y su versión; ahí es donde leo el feedback.
El código que publicas siempre ha sido legible. Desde hoy, lo que alguien aprende de una release ya no tiene por qué servir para la siguiente.
— Nikita