Softonic

Obfuscateur JavaScript

Étape 1 / 2
Mode
Suivant

L’obfuscation augmente le coût de lecture de votre code source JavaScript, pas de manière absolue (aucune obfuscation front-end n’est infaillible) mais suffisamment pour décourager l’inspection occasionnelle et ralentir le scraping automatisé. Cet outil applique l’encodage de tableau de chaînes, le renommage d’identifiants, l’aplatissement de flux de contrôle et l’injection de code mort optionnelle, chaque option étant sélectionnable selon le niveau d’agressivité souhaité.

Comment obfusquer JavaScript

  1. 1

    Collez le code source

    Tout JS valide. S'il dépend de noms de propriétés globales spécifiques d'une page hôte, définissez-les comme réservés.

  2. 2

    Choisissez des techniques

    Encodage de chaînes (hex / base64), renommage d'identifiants, aplatissement de flux de contrôle, injection de code mort, wrapper auto-défensif.

  3. 3

    Choisissez le profil cible

    Navigateur (sûr ES5, pas d'API Node), Node.js (permet `require`, `Buffer`), ou faible (principalement minifier).

  4. 4

    Obfusquer

    L'outil génère le code transformé avec un delta de taille. Des paramètres agressifs peuvent rendre la sortie 3-5x plus grande que la source.

Techniques et ce qu’elles vous coûtent

Technique Augmente l’effort de l’attaquant Coût d’exécution Coût de taille
Renommage de variables Faible Négligeable Plus petit (effet secondaire de minification)
Encodage de tableau de chaînes Moyen Minime (une recherche par chaîne) +10-30%
Aplatissement de flux de contrôle Élevé Mesurable (~2-5%) +50-150%
Injection de code mort Faible (théâtre de sécurité) Petit +20-50%
Wrapper auto-défensif Moyen Vérification unique +5-10%
Protection contre le débogage Moyen (détecte DevTools) Vérification unique +5%
VM / virtualisation (premium) Très élevé Grand (5-20x) +300-500%

Ce que l’obfuscation ne peut pas protéger

  • Secrets. Toute constante dans votre code source front-end est lisible avec suffisamment de temps. Clés API, secrets d’authentification, logique de tarification, ne comptez jamais sur l’obfuscation pour cacher cela. Déplacez-les côté serveur.
  • Algorithmes avec une sortie observable. Si le navigateur peut l’exécuter, un attaquant avec un débogueur peut observer chaque entrée et sortie. L’obfuscation ralentit cela ; elle ne l’arrête pas.
  • Scraping automatisé à grande échelle. La lutte contre le scraping dépend de la détection comportementale (empreintes digitales, limites de taux, CAPTCHA), pas de l’obfuscation du code source.

Quand l’obfuscation en vaut la peine

  • Anti-tampering sur les SDK intégrés (licences, SDK publicitaires, clients de jeux).
  • Augmenter le coût pour un copier-coller à faible effort d’une implémentation concurrente.
  • Rendre la classification des scripts automatisés plus difficile pour les scrapers à large spectre.

Quand c’est contre-productif

  • Vous avez déjà un bundler. Webpack + Terser en mode production minifie et renomme déjà les locaux. Ajouter un second passage d’obfuscation vous apporte peu et gonfle la taille du bundle.
  • Vous optimisez pour le premier rendu / Core Web Vitals. L’obfuscation agressive triple le bundle ; cela nuit au FCP et au LCP.
  • Vous devez déboguer en production. Une forte obfuscation rend les traces de pile Sentry presque inutiles sans une carte source correspondante, et expédier la carte source contredit l’obfuscation.

Erreurs courantes

  • Traiter l’obfuscation comme équivalente au chiffrement. Ce n’est pas le cas, c’est un simple ralentisseur.
  • Expédier la carte source avec le bundle obfusqué en production. Cela neutralise complètement l’obfuscation.
  • Obfusquer des bibliothèques tierces que vous avez déjà chargées depuis un CDN. Vous subissez la pénalité de taille sans aucun gain.

Questions fréquentes

Non. L’obfuscation est un obstacle, pas une serrure. Un analyste déterminé avec un débogueur récupérera la logique. Cela augmente le coût suffisamment pour décourager l’inspection occasionnelle et la plupart des scrapers automatisés, mais ce n’est pas de la sécurité.

Si vous accédez aux propriétés de manière dynamique (obj["field_name"], Object.keys(obj)), ou si vous dépendez de noms de fonctions / classes spécifiques pour la page hôte, ajoutez-les à la liste réservée. Sans cela, le renommage des propriétés peut casser les intégrations externes.

Conservez le code source original. L’obfuscateur est une transformation unidirectionnelle ; vous ne pouvez pas récupérer exactement l’original à partir de la sortie obfusquée, seulement une approximation lisible.

Une légère obfuscation ajoute ~10-30%. L’aplatissement de flux de contrôle plus les tableaux de chaînes ajoute 50-150%. Les paramètres les plus lourds peuvent tripler la taille. Vérifiez le compteur de taille de sortie avant d’expédier.

Outils similaires

Référence de la table ASCII

Table ASCII complète de 0 à 127 avec décimal, hexadécimal, octal, binaire et référence numérique HTML pour chaque caractère, y compris les codes de contrôle comme NUL, LF et DEL.

Référence des caractères HTML

Liste consultable des entités HTML, de leurs codes nommés et numériques, et un copier-coller en un clic pour les caractères et symboles spéciaux.

Compteur de FPS

Mesurez les FPS du navigateur avec requestAnimationFrame : lissage, fréquence d'images min et max, seuil d'alerte et graphique facultatif. Tout se passe en local, sans envoi ni API.

Référence des raccourcis clavier

Recherchez les raccourcis par défaut documentés de VS Code, Chrome et Bash avec GNU Readline sous macOS, Windows et Linux.

Générateur de carte CSS

Créez le CSS d’un conteneur de carte : fond, bordure, rayon des angles, espacement intérieur et ombre douce, avec aperçu immédiat et code à copier-coller.

Formateur HTML

Mettez du HTML en forme localement dans le navigateur avec une indentation de deux ou quatre espaces. Aucun HTML n’est envoyé ni validé.

Outil disponible dans d’autres langues