Article
Encoder et décoder des données en privé
Les développeurs collent chaque jour des jetons, des charges utiles et des identifiants dans des pages d'encodage et de décodage. Les plus pratiques tournent sur un serveur, ce qui veut dire que vos données quittent votre machine pour une tâche qui ne l'exigeait pas. Ces quatre outils s'exécutent entièrement dans votre navigateur, vos données restent donc chez vous.
Base64 : ça paraît brouillé, ce n'est pas secret
Le Base64 est un encodage, pas un chiffrement. Il transforme des données binaires en texte capable de survivre à un copier-coller ou au transit par des systèmes qui ne gèrent que des caractères simples. Quiconque voit la chaîne Base64 peut la redécoder en une seule étape, donc une chaîne contenant une clé d'API, un certificat privé ou le corps d'un courriel reste parfaitement lisible pour celui qui la détient. Le danger, c'est que cette valeur se cache souvent dans des fichiers de configuration, des data URL ou des en-têtes d'authentification et paraît obscure, ce qui pousse à la coller dans le premier décodeur trouvé en ligne. Ce décodeur reçoit le secret brut. Un outil qui décode le Base64 localement vous montre les octets d'origine sans que la valeur n'atteigne jamais un serveur.

Encodage d'URL : les chaînes de requête en disent long
L'encodage en pourcentage permet de placer sans risque des espaces, des accents et des caractères réservés dans une URL. Le texte que vous encodez ou décodez est souvent une vraie chaîne de requête issue d'une application, et celle-ci transporte des identifiants de session, des termes de recherche, des adresses e-mail, des cibles de redirection et parfois des paramètres signés. Coller une URL complète dans un encodeur distant remet tout cela d'un coup à un tiers, et les chaînes de requête sont précisément le genre de valeur qui finit dans les journaux serveur. Encoder et décoder dans le navigateur signifie que l'URL est traitée en mémoire sur votre propre appareil et n'est jamais transmise pendant votre travail.
JWT : la charge utile est signée, pas cachée
Un jeton web JSON se compose de trois sections Base64url reliées par des points : un en-tête, une charge utile et une signature. La signature prouve que le jeton n'a pas été altéré, mais elle ne dissimule en rien la charge utile, qui se décode en JSON clair contenant des identifiants d'utilisateur, des rôles, des dates d'expiration et toutes les revendications personnalisées ajoutées par l'émetteur. Un jeton valide est aussi un identifiant actif : jusqu'à son expiration, quiconque le détient peut agir au nom de l'utilisateur. Coller un jeton fonctionnel dans un décodeur en ligne envoie un identifiant actif à un serveur que vous ne contrôlez pas. Un décodeur qui analyse le jeton dans votre navigateur révèle le même en-tête et la même charge utile sans que ce jeton ne quitte jamais la page.

Hachage : l'entrée compte plus que l'empreinte
Une fonction de hachage transforme n'importe quelle entrée en une empreinte de longueur fixe, et vous ne pouvez pas inverser l'empreinte pour retrouver l'entrée. Cette propriété rend le hachage utile pour vérifier l'intégrité d'un fichier ou comparer des valeurs sans stocker l'original. Le piège se situe du côté de l'entrée : pour calculer le hachage d'un mot de passe, d'un document ou d'un secret de configuration, vous devez fournir la vraie valeur à l'outil. Si cet outil tourne sur un serveur, l'entrée sensible y voyage alors que seule l'empreinte inoffensive est renvoyée. Calculer le hachage localement garde l'entrée sur votre appareil, vous obtenez donc l'empreinte voulue sans exposer la chose que vous hachiez.
Encodage Base64 : correspondance d'octets et rembourrage
Base64 traduit des octets 8 bits en caractères 6 bits en regroupant trois octets d'entrée (24 bits) en quatre valeurs de 6 bits. Chaque valeur de 6 bits correspond à un caractère de l'alphabet Base64 (A-Z, a-z, 0-9, +, /). Le processus nécessitant des entrées divisibles par 24 bits, les entrées courtes sont complétées : un octet restant produit deux caractères de rembourrage (==), deux octets restants en produisent un (=). La variante Base64url, utilisée dans les JSON Web Tokens (JWT), remplace + par - et / par _ pour rendre la chaîne compatible avec les URL, et supprime entièrement le rembourrage =, car ces caractères peuvent provoquer des erreurs dans les analyseurs d'URI stricts. Cette distinction est importante lors du débogage de la gestion des tokens : un JWT qui semble mal formé peut simplement être encodé en Base64url plutôt qu'en Base64 standard.
Signatures JWT : HS256, RS256 et confusion d'algorithme
La sécurité d'un JSON Web Token repose entièrement sur sa signature, le troisième segment séparé par un point. Avec HS256 (HMAC-SHA256), le serveur signe l'en-tête et le corps encodés en Base64url à l'aide d'une clé secrète. La résistance aux collisions de SHA-256 rend impossible, en pratique, de produire un corps modifié qui aboutit à la même signature sans connaître la clé secrète. Avec RS256, le serveur signe avec une clé privée RSA et vérifie avec une clé publique. Une vulnérabilité connue, dite de confusion d'algorithme, survient lorsque la bibliothèque serveur n'applique pas strictement le type d'algorithme attendu. Un attaquant peut modifier le champ alg de l'en-tête du token de RS256 à HS256 et signer le token en utilisant la clé publique du serveur comme secret HMAC, celle-ci étant souvent accessible. Décoder l'en-tête JWT localement dans le navigateur permet de vérifier quel algorithme est effectivement spécifié, sans exposer le token actif aux systèmes de journalisation tiers.
Outils mentionnés dans cet article
- Encodeur / Décodeur Base64Encodez ou décodez du Base64, texte et fichiers. Aucun upload, 100 % local.
- Encodeur / Décodeur URLEncodez ou décodez des chaînes URL en pourcentage. Aucun upload, 100 % local.
- Décodeur JWTDécodez un JWT (en-tête, payload, expiration) sans l'envoyer nulle part. Pas de vérification de signature.
- Générateur de hashGénérez des hash MD5, SHA-1, SHA-256, SHA-512 depuis du texte ou des fichiers. Aucun upload.
Questions fréquentes
Le Base64 ou l'encodage d'URL est-il une forme de sécurité ?
Non. Ce sont deux encodages réversibles conçus pour le transport sûr des données, pas pour les protéger. Quiconque peut lire la chaîne encodée la décode instantanément, sans clé ni mot de passe. Si vous devez garder une valeur confidentielle, chiffrez-la avec un algorithme adéquat et gérez la clé séparément. Traitez toute valeur en Base64 ou encodée en pourcentage comme si elle était écrite en clair.
Pourquoi l'endroit où je décode un jeton ou hache un mot de passe a-t-il de l'importance ?
Parce que l'entrée est la partie sensible. Un JWT valide est un identifiant actif, et le mot de passe que vous hachez est le véritable secret. Un outil hébergé sur un serveur reçoit cette entrée brute avant même de renvoyer un résultat, ce qui veut dire qu'une copie peut être journalisée ou conservée à un endroit que vous ne voyez pas. Un outil qui s'exécute dans votre navigateur réalise la même opération en mémoire sur votre propre machine, le jeton ou le mot de passe n'est donc jamais envoyé nulle part.