JavaScriptOfuscación VM

Hay muchos motivos para proteger tu código: evitar que cualquiera se limite a copiar tu trabajo (algo especialmente importante en proyectos de cliente como los juegos HTML5), hacer que el código sea más difícil de entender y modificar, y proteger un trabajo que aún no se ha cobrado para poder enseñar a los clientes una compilación funcional sin entregarles el código fuente.

La ofuscación estándar reescribe tu JavaScript como un JavaScript más difícil de leer: se sustituyen los nombres, se trasladan y codifican las cadenas y se reestructura el flujo de control, pero el resultado sigue siendo JavaScript que un depurador puede recorrer paso a paso. La ofuscación VM (máquina virtual) compila los cuerpos de tus funciones a bytecode personalizado e incluye un intérprete incrustado que lo ejecuta, de modo que la lógica protegida ya no existe como JavaScript. Consulta Ofuscación VM para ver qué funciones se cubren y cómo seleccionarlas.

Sí. Establece vmTargetFunctionsMode en comment y marca cada función que quieras proteger con /* javascript-obfuscator:vm */. Conserva esos comentarios a lo largo de cualquier paso de compilación que se ejecute antes de la ofuscación. Consulta Selección de funciones específicas.

No. Las claves de API, los secretos y las credenciales NUNCA deben almacenarse en el código del frontend. Incluso con el nivel de ofuscación más alto, cualquier dato presente en el JavaScript del frontend puede ser extraído por un atacante decidido. La ofuscación dificulta la ingeniería inversa, pero no es cifrado y no debe utilizarse para proteger secretos. En su lugar, guarda los secretos en tu servidor backend, usa variables de entorno en el lado del servidor, redirige las llamadas a la API a través de tu backend para ocultar las claves o utiliza tokens de corta duración emitidos por tu servidor.

La ofuscación aumenta el esfuerzo para entender y modificar código, tanto si el análisis lo hace una persona, una herramienta o un asistente de IA, pero no garantiza que la ingeniería inversa sea imposible. La ejecución sigue siendo observable en un entorno controlado por un atacante. Mantén secretos y decisiones de seguridad definitivas en el servidor. Cómo transforma el código la VM.

Primero descarta las defensas en tiempo de ejecución. VM Self Defending y VM Debug Protection fallan a propósito con herramientas de automatización, navegadores headless y depuradores, y cuando target no coincide con el entorno real, así que ejecuta las pruebas funcionales con una compilación de prueba aparte que las desactive. Si esa compilación también falla, acota el problema con vmTargetFunctionsMode: 'comment' para virtualizar una función cada vez. La guía de solución de problemas recorre cada paso e indica qué incluir en un informe de error.

El ofuscador añade código: los identificadores reciben nombres generados, las cadenas pasan a un array de cadenas con funciones de acceso (opcionalmente codificado) y, con la ofuscación VM, se incluye todo un intérprete de máquina virtual junto con tu bytecode. No te preocupes demasiado por el tamaño: el código ofuscado se comprime bien con gzip o Brotli, que la mayoría de los servidores activan de forma predeterminada.

Los preajustes más intensivos pueden aumentar el tamaño de salida y el tiempo de ejecución. Mide el arranque, las rutas frecuentes y el tamaño comprimido de tu bundle en vez de asumir multiplicadores fijos de ralentización. Referencia de opciones · Buenas prácticas

No. Reescribir la salida puede romperla, sobre todo con Self Defending o VM Self Defending, que detectan cambios en el código. Puedes pasar un minificador antes de la ofuscación, siempre que conserve los comentarios de javascript-obfuscator como /* javascript-obfuscator:vm */.

No guardamos tu código fuente. La ofuscación básica de JavaScript se ejecuta en tu navegador. La ofuscación VM y la de HTML envían el código a nuestros servidores, que lo procesan y lo descartan; cuando una solicitud supera 4.4 MB, los planes Team y Business lo suben a un almacenamiento temporal que se elimina tras el procesamiento. Para gestionar abusos y analizar el uso conservamos durante tres meses un hash SHA-256 de cada salida ofuscada y algunos de los ajustes usados (como el preajuste, el target y las defensas de la VM), nunca el código en sí ni ningún contenido suyo. El historial del panel se guarda solo en tu navegador; gestiónalo desde Historial.

No. El ofuscador no conserva tus nombres originales, comentarios ni formato, así que la salida no puede volver a convertirse en tu código fuente. Eso no es una garantía de seguridad (consulta más arriba la pregunta sobre la desofuscación), pero sí significa que debes guardar bien el original.

Sí. Puedes seleccionar "Node" como Target en las opciones de ofuscación para optimizar la salida para entornos Node.js.

Se admite sintaxis ES2015+, async/await, encadenamiento opcional y campos privados de clase; prueba la sintaxis más reciente con la versión del ofuscador que elijas. Compila TypeScript y JSX y empaqueta tu aplicación antes de ofuscarla: consulta Compatibilidad de ejecución. Los archivos HTML se admiten mediante parseHtml; consulta Ofuscación de HTML.

La salida ofuscada, incluidos el intérprete de la VM y la capa Self Defending, se mantiene y se prueba de forma activa en los navegadores de escritorio evergreen y en iOS 16 o superior (aproximadamente los últimos 4 años). Los navegadores más antiguos funcionan en la medida de lo posible hasta un mínimo absoluto de compatibilidad con módulos ES2015; todo lo anterior a eso, incluido Internet Explorer, queda fuera del alcance.

Consulta nuestros planes de precios para obtener protección VM o usa la zona de pruebas gratuita en línea para la ofuscación estándar. Lee la guía de primeros pasos para un recorrido completo.