JavaScriptOfuscación VM

Hay muchos motivos para proteger tu código: evitar que cualquiera se limite a copiar y pegar tu trabajo (algo especialmente importante en proyectos de cliente como los juegos HTML5), eliminar comentarios y espacios en blanco para que el código cargue más rápido y sea más difícil de entender, y proteger un trabajo que aún no se ha cobrado para poder enseñárselo a los clientes sin entregarles el código fuente.

La ofuscación VM (máquina virtual) transforma tu código JavaScript en bytecode personalizado que se ejecuta en un intérprete incrustado. A diferencia de la ofuscación estándar, que sigue generando JavaScript legible, la ofuscación VM oculta por completo la estructura de tu código original. Las herramientas de análisis estático no pueden entender la lógica sin aplicar antes ingeniería inversa a toda la máquina virtual. Más información en nuestra guía de ofuscación VM.

¡Sí! Ofrecemos una opción para aplicar la ofuscación VM de forma selectiva a funciones o métodos concretos. Basta con anotar la función de destino con un comentario especial (/* javascript-obfuscator:vm */) para que solo esa función pase por el ofuscador VM. Es ideal para proteger únicamente tus algoritmos más sensibles y dejar el resto del código con ofuscación estándar o sin tocar, reduciendo al mínimo la sobrecarga de rendimiento.

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.

Ninguna ofuscación es infalible al 100 %: JavaScript acaba ejecutándose en un entorno que controla el atacante, ya sea el navegador o Node.js, y ahí la inspección de la memoria en tiempo de ejecución siempre es posible. Ninguna ofuscación de JavaScript puede impedirlo; lo que sí puede hacer es encarecer el coste de llegar hasta ella. Hoy por hoy no existen servicios en línea de desofuscación automática para el código protegido con VM: cada ofuscación compila el código en un bytecode propio con una máquina virtual única, lo que hace imposible crear herramientas universales. La ofuscación estándar es mucho más fácil de vencer: a menudo se puede revertir parcialmente con herramientas automáticas y embellecedores de código. La ofuscación VM exige aplicar ingeniería inversa completa a la máquina virtual, descifrar y descodificar su bytecode, entender su conjunto de instrucciones y trazar la ejecución, un proceso que puede llevar semanas de trabajo dedicado. Sin VM Self Defending, los agentes de IA más potentes (por ejemplo, Claude Opus 4.7) pueden trazar el bytecode y reconstruir de forma aproximada el código original en bases de código pequeñas. Con VM Self Defending activado, las defensas anti-LLM en capas (antihooking, verificación de integridad entre realms y comprobaciones de nativez del bytecode) desbaratan las técnicas dinámicas que un agente necesita para dar sentido al bytecode: instrumentación, hooking y ejecución en sandbox. Sigue siendo posible leer el archivo de forma estática, pero solo expone bytecode opaco, y cada intento de observar el runtime que lo interpreta activa una comprobación de integridad. Solo con el archivo, la desofuscación automática con IA resulta inviable. Para reforzar aún más tu código: envuelve las funciones sensibles en una IIFE para que sus nombres se transformen por completo y activa opciones de refuerzo como el cifrado del bytecode. Más información sobre cómo transforma el código la VM.

La ofuscación VM es una tecnología compleja y puede que algunos casos límite no sean totalmente compatibles. Si tu código deja de funcionar tras la ofuscación VM, puedes acotar el problema usando vmTargetFunctionsMode: 'comment' para ofuscar de forma selectiva solo determinadas funciones. Consulta nuestra guía de resolución de problemas para ver instrucciones paso a paso sobre cómo identificar el código problemático e informar del fallo.

El ofuscador introduce código nuevo para protegerse frente a la depuración y la ingeniería inversa. Las cadenas se convierten a hexadecimal 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 extremadamente bien con GZIP, que la mayoría de los servidores activan de forma predeterminada.

Cualquier ofuscación tiene cierto impacto en el rendimiento. La ofuscación estándar apenas añade sobrecarga. La ofuscación VM tiene mucho más impacto y depende en gran medida del código: por ejemplo, el código con mucha recursión convertido a bytecode será notablemente más lento. De media, el preajuste low multiplica el coste por unas 10x, y el preajuste anti-LLM con Self Defending y Debug Protection resulta unas 12x más lento. Puedes ajustar el equilibrio modificando las opciones o aplicando la ofuscación VM solo a las secciones de código sensibles. Consulta nuestra guía de buenas prácticas para ver consejos de optimización.

No, no es recomendable y en algunos casos romperá el código (sobre todo si activas self-defending). Lo que sí puedes hacer es pasar tu código por un minificador antes de ofuscarlo.

En los archivos de menos de 4.4 MB, el código fuente se procesa íntegramente en memoria y se devuelve de inmediato como salida ofuscada. En los archivos más grandes (planes Team y Business), los subimos temporalmente a un almacenamiento seguro y los eliminamos en cuanto termina la ofuscación. Como medida adicional, cada 5 minutos se ejecuta una tarea de limpieza que borra cualquier archivo con más de 5 minutos de antigüedad. Tu código nunca se conserva.

No, es imposible revertir el código ofuscado a tu código original, así que guarda bien el original.

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

Admitimos ES2015 (ES6) y todas las características modernas de JavaScript, incluida la sintaxis ES2022+, los campos privados de clase, async/await, el encadenamiento opcional y mucho más. TypeScript y JSX deben compilarse a JavaScript antes de la ofuscación. Con un plan de pago también puedes ofuscar archivos HTML: añade el atributo data-javascript-obfuscator a las etiquetas <script> que quieras proteger y se ofuscarán una a una conservando la estructura del HTML. Ten en cuenta que el código de cada script marcado debe ser autónomo (sin referencias a otros scripts) y que los scripts de módulos ES se omiten.

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 3 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.