Décoder du Base64

Regardez ce que les gens collent dans un décodeur Base64. Un JWT, pour savoir à qui appartient le token. Une valeur sortie d’un secret Kubernetes, c’est-à-dire un mot de passe écrit de façon à ne pas en avoir l’air. Un en-tête Basic tiré d’un journal de requêtes. Un payload de webhook venu de la production. Trois de ces quatre sont des identifiants, et le quatrième est en général une donnée client.

Un décodeur qui travaille sur un serveur les a tous vus, et il les a dans ses journaux d’accès, que quelqu’un ait voulu les garder ou non. Ce n’est pas un risque théorique : c’est pourquoi ce genre de site est bloqué au proxy dans beaucoup d’organisations. Cette page fait l’arithmétique dans votre onglet, et l’onglet réseau est la façon de le vérifier plutôt qu’une promesse à prendre pour argent comptant.

Un JSON Web Token est fait de trois segments Base64 compatibles URL séparés par des points. Collez celui du milieu et vous obtenez le payload : les claims, le sujet, l’expiration sous forme de timestamp Unix. Collez le premier et vous obtenez l’en-tête, qui nomme l’algorithme de signature. Les deux sont lisibles par quiconque détient le token, ce qui surprend et ne devrait pas — un JWT est signé, pas chiffré.

Ce que le décodage ne peut pas vous dire, c’est si le token est valide. Le troisième segment est une signature sur les deux premiers, et la vérifier demande la clé. Cette page vous montrera donc qu’un token prétend expirer mardi prochain ; elle ne vous dira pas si quelqu’un a modifié ce claim. Si vous vous appuyez sur le contenu, vérifiez la signature là où le secret se trouve.

Base64 transporte des octets, et des octets ne sont pas toujours des caractères. Décodez le début d’un PNG et vous obtenez une signature, une longueur de bloc et du binaire — au mieux une suite de caractères de remplacement, au pire du mojibake. La plupart des décodeurs vous les donnent quand même, ce qui vous laisse devant du charabia sans savoir si l’entrée était fausse ou si le contenu n’est simplement pas du texte.

Celui-ci le dit. Le décodeur est strict sur l’UTF-8 : des octets qui ne forment pas de texte valide sont signalés comme tels, avec leur nombre, plutôt que remplacés discrètement par des U+FFFD. « Du Base64 valide qui contient un fichier » et « ce n’est pas du Base64 » sont deux problèmes différents, et ils reçoivent deux réponses différentes.

Le remplissage est facultatif ici. Un segment de JWT n’en porte pas, puisque `=` est réservé dans une URL, et un décodeur qui l’exige rejette tous les vrais tokens — c’est une spécification appliquée contre l’intégralité de la population qu’elle décrit. Les espaces et les retours à la ligne sont retirés, parce qu’un bloc PEM copié depuis un terminal arrive coupé tous les soixante-quatre caractères et que personne ne va le recoller à la main.

Les deux alphabets sont acceptés sans qu’on vous demande lequel vous tenez. Le Base64 standard finit par `+` et `/` ; la variante compatible URL emploie `-` et `_`. Ils ne peuvent pas être confondus l’un avec l’autre, le décodeur traduit donc les deux, et il n’y a aucun réglage à se tromper.

La cause la plus fréquente est une copie qui a emporté quelque chose en plus : un point final, un guillemet venu du JSON qui l’entourait, ou le préfixe `data:image/png;base64,` d’une data URI, qui est une métadonnée et non la charge. Base64 n’emploie que A–Z, a–z, 0–9 et deux symboles : tout le reste est un indice sur l’endroit où la copie a dérapé.

La deuxième cause la plus fréquente est une copie partielle. Les terminaux coupent les lignes et les sélections s’arrêtent trop tôt, et le Base64 ne donne aucun signe d’être tronqué : il décode la partie qu’il a et produit un texte qui s’arrête au milieu d’un mot, ou échoue sur une longueur qui n’est plus un multiple de quatre. Si la sortie s’arrête bizarrement, vérifiez l’entrée pour la même raison.

Un objet `Secret` stocke ses valeurs en Base64, et beaucoup de gens en concluent qu’elles sont protégées. Elles ne le sont pas : l’encodage sert à faire tenir des octets arbitraires dans du YAML, rien de plus. Quiconque peut lire le manifeste peut lire le mot de passe, et c’est précisément pour cela que les droits d’accès sur ces objets sont le vrai mécanisme de protection.

La conséquence pratique est qu’un manifeste collé dans un ticket, une capture d’écran de tableau de bord ou un fichier de valeurs versionné par erreur expose des identifiants en clair, à un décodage près. C’est aussi pourquoi décoder l’un d’eux sur un site distant est exactement le geste à ne pas faire, et pourquoi cette page a été écrite comme elle l’a été.

Il arrive qu’une valeur ait été encodée deux fois, souvent parce qu’une bibliothèque le fait déjà et qu’un script le refait. Le signe est net : le résultat du premier décodage ressemble encore à du Base64 — uniquement des lettres, des chiffres, éventuellement un `=` final — au lieu de ressembler à du texte.

Décodez une seconde fois et vous obtenez la valeur réelle. Il vaut la peine de remonter à la cause plutôt que de décoder deux fois par habitude : un double encodage rallonge la valeur d’environ un tiers à chaque passage, et une chaîne qui traverse trois systèmes en gagnant un tiers à chaque fois finit par dépasser une limite de champ que personne n’avait vue venir.

Une valeur encodée depuis un texte français décode en octets UTF-8, où `é` vaut `c3 a9` et `ç` vaut `c3 a7`. Un décodeur qui interprète ces octets comme du Latin-1 affiche deux caractères là où il en faudrait un : le fameux `é` à la place de `é`, qui est le signe le plus reconnaissable d’un décodage fait avec le mauvais jeu de caractères.

Le problème n’est jamais dans le Base64 lui-même, qui a restitué les octets exacts qu’on lui avait donnés. Il est dans l’étape suivante, celle qui transforme des octets en caractères. Cette page lit toujours en UTF-8, et signale explicitement les octets qui ne forment pas de texte valide plutôt que de produire un mot approximatif.

Rien. Le résultat est du texte dans la page, il n’est écrit ni dans le stockage local, ni dans un cookie, ni dans un journal, et fermer l’onglet le fait disparaître. Il n’y a pas d’historique des valeurs décodées, et cette absence est délibérée : un historique serait pratique deux fois par mois et gênant le reste du temps.

C’est aussi ce qui rend l’outil utilisable sur un poste partagé ou sur une machine qui n’est pas la vôtre. Le seul endroit où la valeur peut subsister est votre presse-papiers, ce qui dépend de votre système et non de cette page.