JavaScriptObfuscation VM

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

L'obfuscation standard réécrit votre JavaScript en un JavaScript plus difficile à lire : les noms sont remplacés, les chaînes déplacées et encodées, le flux de contrôle restructuré, mais le résultat reste du JavaScript qu'un débogueur peut parcourir pas à pas. L'obfuscation VM (machine virtuelle) compile le corps de vos fonctions en bytecode sur mesure et livre un interpréteur embarqué qui l'exécute : la logique protégée n'existe donc plus sous forme de JavaScript. Consultez Obfuscation VM pour savoir quelles fonctions sont couvertes et comment les sélectionner.

Oui. Réglez vmTargetFunctionsMode sur comment, puis marquez chaque fonction à protéger avec /* javascript-obfuscator:vm */. Conservez ces commentaires à travers toute étape de build exécutée avant l'obfuscation. Voir Cibler des fonctions spécifiques.

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 API par votre backend pour masquer les clés, ou utilisez des jetons de courte durée émis par votre serveur.

L'obfuscation augmente l'effort nécessaire pour comprendre et modifier le code, que l'analyse soit menée par une personne, un outil ou un assistant IA, sans garantir l'impossibilité de la rétro-ingénierie. L'exécution reste observable dans un environnement contrôlé par l'attaquant. Gardez les secrets et les décisions de sécurité faisant autorité sur le serveur. Comment la VM transforme le code.

Écartez d'abord les défenses à l'exécution. VM Self Defending et VM Debug Protection cassent volontairement l'exécution sous des outils d'automatisation, des navigateurs headless et des débogueurs, ainsi que lorsque target ne correspond pas à l'environnement réel : lancez donc vos tests fonctionnels sur un build de test distinct où elles sont désactivées. Si ce build échoue encore, isolez le problème avec vmTargetFunctionsMode: 'comment' en virtualisant une fonction à la fois. Le guide de dépannage détaille chaque étape et ce qu'il faut joindre à un rapport de bug.

L'obfuscateur ajoute du code : les identifiants reçoivent des noms générés, les chaînes sont déplacées dans un tableau de chaînes accompagné de fonctions d'accès (éventuellement encodé) 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 bien avec gzip ou Brotli, que la plupart des serveurs activent par défaut.

Les préréglages plus lourds peuvent augmenter la taille de sortie et le temps d'exécution. Mesurez le démarrage, les chemins fréquents et la taille compressée de votre bundle plutôt que de compter sur des facteurs de ralentissement fixes. Référence des options · Bonnes pratiques

Non. Réécrire la sortie peut la casser, en particulier avec Self Defending ou VM Self Defending, qui détectent les modifications du code. Vous pouvez passer un minifieur avant l'obfuscation, à condition qu'il conserve les commentaires javascript-obfuscator comme /* javascript-obfuscator:vm */.

Nous ne conservons pas votre code source. L'obfuscation de base du JavaScript s'exécute dans votre navigateur. L'obfuscation VM et HTML envoie le code source à nos serveurs, qui le traitent puis le suppriment ; lorsqu'une requête dépasse 4.4 Mo, les forfaits Team et Business l'envoient vers un stockage temporaire supprimé après traitement. Pour la gestion des abus et l'analyse de l'utilisation, nous conservons pendant trois mois une empreinte SHA-256 de chaque sortie obfusquée et quelques-uns des paramètres utilisés (comme le préréglage, la cible et les défenses de la VM), jamais le code lui-même ni aucun de ses contenus. L'historique du tableau de bord est stocké uniquement dans votre navigateur ; gérez-le depuis Historique.

Non. L'obfuscateur ne conserve ni vos noms d'origine, ni vos commentaires, ni votre mise en forme : la sortie ne peut donc pas être reconvertie en votre code source. Ce n'est pas une garantie de sécurité (voir la question sur la désobfuscation ci-dessus), mais cela signifie que vous devez conserver précieusement l'original.

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

La syntaxe prise en charge comprend ES2015+, async/await, le chaînage optionnel et les champs privés de classe ; testez la syntaxe plus récente avec la version de l'obfuscateur que vous choisissez. Compilez TypeScript et JSX et regroupez votre application avant l'obfuscation - voir Compatibilité d'exécution. Les fichiers HTML sont pris en charge via parseHtml ; voir Obfusquer des fichiers HTML.

La sortie obfusquée - y compris l'interpréteur de la VM et la couche Self Defending - est activement prise en charge et testée sur les navigateurs de bureau à mise à jour continue ainsi que sur iOS 16+ (soit environ les 4 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.