JavaScriptObfuscation VM

Les raisons de protéger son code sont nombreuses : empêcher quiconque de simplement copier-coller votre travail (ce qui compte particulièrement pour les projets côté client comme les jeux HTML5), supprimer les commentaires et les espaces afin de rendre le code plus rapide à charger et plus difficile à comprendre, et protéger un travail qui n'a pas encore été payé pour pouvoir le montrer à un client sans lui livrer le code source.

L'obfuscation VM (machine virtuelle) transforme votre code JavaScript en bytecode sur mesure exécuté par un interpréteur embarqué. Contrairement à l'obfuscation standard, qui produit toujours du JavaScript lisible, l'obfuscation VM masque complètement la structure de votre code d'origine. Les outils d'analyse statique ne peuvent pas en comprendre la logique sans faire au préalable la rétro-ingénierie de toute la machine virtuelle. Pour en savoir plus, consultez notre guide de l'obfuscation VM.

Oui ! Nous proposons une option permettant d'appliquer l'obfuscation VM de façon sélective à certaines fonctions ou méthodes. Il vous suffit d'annoter la fonction visée avec un commentaire spécial (/* javascript-obfuscator:vm */) : seule cette fonction sera traitée par l'obfuscateur VM. C'est idéal pour ne protéger que vos algorithmes les plus sensibles tout en laissant le reste de votre code en obfuscation standard ou intact, ce qui réduit au minimum la perte de performances.

Non. Les clés API, les secrets et les identifiants ne doivent JAMAIS être stockés dans du code frontend. Même avec le plus haut niveau d'obfuscation, toute donnée présente dans du JavaScript frontend peut être extraite par un attaquant déterminé. L'obfuscation rend la rétro-ingénierie plus difficile, mais ce n'est pas du chiffrement et elle ne doit pas servir à protéger des secrets. Stockez plutôt vos secrets sur votre serveur backend, utilisez des variables d'environnement côté serveur, faites transiter les appels d'API par votre backend pour masquer les clés, ou utilisez des jetons de courte durée émis par votre serveur.

Aucune obfuscation n'est fiable à 100 % : le JavaScript finit toujours par s'exécuter dans un environnement contrôlé par l'attaquant — navigateur ou Node.js — où l'inspection de la mémoire à l'exécution reste toujours possible. Aucune obfuscation JavaScript ne peut supprimer cette possibilité ; ce qu'elle peut faire, c'est en augmenter le coût. Il n'existe aujourd'hui aucun service en ligne de désobfuscation automatique pour le code obfusqué par VM : chaque obfuscation compile le code en un bytecode sur mesure doté d'une machine virtuelle unique, ce qui rend tout outillage universel impossible. L'obfuscation standard est bien plus facile à contourner : elle peut souvent être partiellement inversée à l'aide d'outils automatisés et d'embellisseurs de code. L'obfuscation VM impose de faire la rétro-ingénierie complète de la machine virtuelle, de déchiffrer et décoder son bytecode, de comprendre son jeu d'instructions et de retracer son exécution — un travail qui peut demander des semaines d'efforts soutenus. Sans l'auto-défense de la VM, des agents d'IA puissants (par exemple Claude Opus 4.7) peuvent suivre le bytecode et reconstituer approximativement le code d'origine sur de petites bases de code. Avec l'auto-défense de la VM activée, des défenses anti-LLM en couches — anti-hooking, vérification d'intégrité inter-realms et contrôles de nativité du bytecode — perturbent les techniques dynamiques dont un agent se sert pour donner du sens au bytecode : instrumentation, hooking et exécution en bac à sable. La lecture statique du fichier reste possible, mais elle n'expose qu'un bytecode opaque, et toute tentative d'observer le runtime qui l'interprète déclenche un contrôle d'intégrité. À partir du seul fichier, la désobfuscation automatisée par IA devient irréalisable. Pour durcir davantage votre code : encapsulez les fonctions sensibles dans une IIFE afin que leurs noms soient entièrement transformés, et activez des options de durcissement comme le chiffrement du bytecode. Découvrez comment la VM transforme le code.

L'obfuscation VM est une technologie complexe et certains cas limites ne sont pas encore entièrement pris en charge. Si votre code cesse de fonctionner après l'obfuscation VM, vous pouvez circonscrire le problème en utilisant vmTargetFunctionsMode: 'comment' pour n'obfusquer que certaines fonctions. Consultez notre guide de dépannage pour la marche à suivre, étape par étape, afin d'identifier le code problématique et de nous signaler le problème.

L'obfuscateur ajoute du code pour se protéger du débogage et de la rétro-ingénierie. Les chaînes sont converties en hexadécimal et, avec l'obfuscation VM, un interpréteur de machine virtuelle complet est livré avec votre bytecode. Ne vous souciez pas trop de la taille : le code obfusqué se compresse extrêmement bien avec GZIP, que la plupart des serveurs activent par défaut.

Toute obfuscation a un certain impact sur les performances. L'obfuscation standard n'engendre qu'une surcharge minime. L'obfuscation VM pèse bien plus lourd, et cela dépend fortement du code : par exemple, du code converti en bytecode et très récursif sera nettement plus lent. En moyenne, le préréglage low multiplie le coût par environ 10, et le préréglage anti-LLM avec auto-défense et protection anti-débogage par environ 12. Vous pouvez ajuster l'équilibre en modifiant les options ou en n'appliquant l'obfuscation VM qu'aux portions de code sensibles. Consultez notre guide des bonnes pratiques pour des conseils d'optimisation.

Non, ce n'est pas recommandé et, dans certains cas, cela cassera le code (en particulier si vous activez l'auto-défense). Vous pouvez en revanche passer votre code dans un minifieur avant l'obfuscation.

Pour les fichiers de moins de 4.4 MB, le code source est traité entièrement en mémoire et renvoyé immédiatement sous forme obfusquée. Pour les fichiers plus volumineux (forfaits Team/Business), nous les téléversons temporairement vers un stockage sécurisé et les supprimons dès la fin de l'obfuscation. Par précaution supplémentaire, une tâche de nettoyage s'exécute toutes les 5 minutes pour supprimer tout fichier de plus de 5 minutes. Votre code n'est jamais conservé.

Non, il est impossible de revenir du code obfusqué à votre code d'origine : conservez donc précieusement l'original.

Oui. Vous pouvez sélectionner « Node » comme cible dans les options d'obfuscation afin d'optimiser la sortie pour les environnements Node.js.

Nous prenons en charge ES2015 (ES6) et toutes les fonctionnalités JavaScript modernes, y compris la syntaxe ES2022+, les champs de classe privés, async/await, le chaînage optionnel, et bien plus encore. TypeScript et JSX doivent être compilés en JavaScript avant l'obfuscation. Avec un forfait payant, vous pouvez également obfusquer des fichiers HTML : ajoutez l'attribut data-javascript-obfuscator aux balises <script> que vous souhaitez protéger, et elles seront obfusquées individuellement tout en préservant la structure du HTML. Notez que le code de chaque script marqué doit être autonome (sans référence à d'autres scripts) et que les scripts de type module ES sont ignorés.

La sortie obfusquée — y compris l'interpréteur de la VM et la couche d'auto-défense — est activement prise en charge et testée sur les navigateurs de bureau à mise à jour continue ainsi que sur iOS 16+ (soit environ les 3 dernières années). Les navigateurs plus anciens sont pris en charge au mieux, jusqu'à un plancher strict correspondant à la prise en charge des modules ES2015 ; tout ce qui se situe en deçà, y compris Internet Explorer, est hors périmètre.

Consultez nos forfaits pour la protection VM, ou essayez le bac à sable en ligne gratuit pour l'obfuscation standard. Lisez le guide de démarrage pour un tour d'horizon complet.