Qu’est-ce que l’encodage Base64 ? Un guide en anglais simple (et pourquoi ce n'est pas un cryptage)

Vous l'avez vu : une longue chaîne de lettres et de chiffres, se terminant peut-être par un ou deux signes égal, située dans un JWT, une source de courrier électronique ou une balise d'image. Il s'agit de Base64, l'un des codages les plus courants en informatique et qu'un nombre surprenant de développeurs utilisent quotidiennement sans savoir ce qu'il fait réellement, ou pire, croyant qu'il fait quelque chose qu'il ne fait pas. Ce guide explique Base64 dans un anglais simple : qu'est-ce que c'est, pourquoi il existe, où vous le rencontrerez et la seule idée fausse dangereuse qui provoque de véritables incidents de sécurité.

Qu'est-ce que Base64 réellement

Base64 est un moyen de représenter des données binaires, n'importe quel octet, en utilisant seulement 64 caractères de texte imprimables : les 26 lettres majuscules, les 26 lettres minuscules, les 10 chiffres et deux symboles, plus (+) et barre oblique (/). Le signe égal (=) est utilisé comme remplissage à la fin. C’est tout l’alphabet, et c’est de là que vient le nom. Chaque caractère de la sortie Base64 est un caractère sûr et imprimable, sans codes de contrôle ni espaces ambigus, ce qui est exactement le point.

La raison pour laquelle il existe est historique et toujours d’actualité. Les principaux protocoles d'Internet, le courrier électronique sur SMTP, les en-têtes HTTP et autres, ont été conçus pour le texte brut. Donnez-leur des données binaires brutes, comme une image ou un blob chiffré, et certaines valeurs d'octets sont interprétées à tort comme des caractères de contrôle et corrompent les données. Base64 résout ce problème en convertissant le binaire en un sous-ensemble de texte qui survit intact à tout canal basé sur du texte. C'est un traducteur entre le monde binaire et le monde textuel.

Comment ça marche, brièvement

L'algorithme prend votre entrée trois octets à la fois. Trois octets correspondent à 24 bits, qu'ils divisent en quatre groupes de 6 bits chacun, et chaque groupe de 6 bits correspond à l'un des 64 caractères. Ainsi, tous les 3 octets d’entrée deviennent exactement 4 caractères de sortie. Lorsque votre entrée n'est pas un multiple propre de 3 octets, Base64 complète la sortie avec des signes égal, un = si le dernier groupe avait 2 octets, deux == s'il n'avait qu'un octet, le résultat est donc toujours un multiple de 4 caractères. C'est ce que signifient ces signes égal à la fin : ils indiquent au décodeur combien d'octets réels se trouvaient dans le groupe final.

Ce rapport de 3 pour 4 a une conséquence directe : la sortie Base64 est environ 33 % plus grande que les données d'origine. Une image de 1 Mo devient environ 1,37 Mo codé. Cette surcharge de taille est le prix que vous payez pour la sécurité des textes, et c'est pourquoi Base64 est idéal pour les petites choses et un mauvais choix pour les grandes.

Où vous rencontrerez Base64

Base64 est partout une fois que vous savez regarder. Les URL de données intègrent un fichier directement en HTML ou CSS, le data:image/png;base64,... que vous voyez parfois dans une balise d'image ou un style d'arrière-plan, permettant à une petite icône de se charger avec la page plutôt que comme une requête distincte. Les pièces jointes des e-mails sont codées en Base64 afin que les fichiers binaires survivent au transport de courrier textuel ; chaque pièce jointe que vous avez envoyée a voyagé de cette façon, c'est pourquoi un fichier de courrier électronique brut est plus volumineux que le fichier qu'il contient.

Les jetons Web JSON (JWT) codent leur en-tête et leur charge utile dans une variante sécurisée pour les URL de Base64. L'authentification HTTP de base envoie votre nom d'utilisateur et votre mot de passe en Base64 dans un en-tête. Les API qui acceptent les téléchargements de fichiers dans un corps JSON encodent le fichier en base64, car JSON est du texte et ne peut pas contenir d'octets bruts. Et les fichiers PEM, les certificats SSL, les clés SSH sont des binaires codés en Base64 enveloppés entre les lignes d'en-tête BEGIN et END. Le même codage simple est à la base de tout cela.

Le mythe dangereux : Base64 n’est pas un cryptage

C’est la chose la plus importante à comprendre, car une erreur entraîne de véritables failles de sécurité. Base64 n'offre aucune sécurité. Ce n'est pas du cryptage. Toute personne disposant de la chaîne codée peut la décoder instantanément, sans clé, sur une seule ligne dans n'importe quelle console de navigateur. La chaîne c2VjcmV0 est décodée en « secret » en une seconde environ.

Le danger vient de l’apparence de Base64. Une chaîne Base64 apparaît brouillée et aléatoire, visuellement similaire à des données cryptées, ce qui fait croire aux gens qu'elles sont protégées. Cela conduit à de véritables incidents : un développeur soumet un fichier de configuration avec les informations d'identification de base de données codées en Base64 au contrôle de version, pensant que l'encodage les cache, ce qui n'est pas le cas. Une API enregistre l'en-tête d'autorisation et un réviseur "ne peut pas lire" le mot de passe Base64, il reste donc dans les journaux sous forme de texte brut jusqu'à ce que quelqu'un le décode en cinq secondes. Stocker une clé API en Base64 dans une base de données semble opaque mais ne protège rien.

Base64 sécurisé pour les URL (Base64url)

La norme Base64 utilise + et /, mais les deux ont une signification particulière dans les URL, + peut signifier un espace dans une chaîne de requête et / délimite les segments de chemin. Ainsi, une variante sécurisée pour les URL appelée Base64url remplace + par - (moins) et / par _ (trait de soulignement), et supprime généralement le remplissage =, qui nécessiterait autrement un codage en pourcentage dans une URL. Il s'agit de la variante utilisée par les JWT, les jetons OAuth et les cookies sécurisés pour les URL. Si jamais vous introduisez un segment JWT dans un décodeur Base64 standard strict et obtenez une erreur ou des déchets, voici généralement la raison : vous devez d'abord reconvertir les caractères sécurisés pour l'URL et restaurer le remplissage.

Le piège Unicode

Un bug subtil pique les développeurs qui encodent en Base64 du texte non anglais. La fonction de navigateur classique btoa() suppose que chaque caractère est un seul octet, qui se divise en lettres accentuées, emoji ou toute écriture non latine. Le correctif consiste à encoder d'abord le texte au format UTF-8, puis à encoder en Base64 les octets résultants, sinon "café" ou "こんにちは" sort corrompu. Un bon encodeur gère cette étape UTF-8 pour vous, donc le texte accentué et les emoji aller-retour proprement.

Quand l’utiliser, quand l’éviter

Utilisez Base64 lorsque vous devez déplacer de petites données binaires via un canal texte uniquement : une petite icône en ligne, un jeton, un petit fichier dans une charge utile JSON, un identifiant que vous déboguez. Évitez-le pour les fichiers binaires volumineux dans des chemins sensibles aux performances, la pénalité de taille de 33 % et la perte de mise en cache séparée font d'un fichier réel ou d'un téléchargement en plusieurs parties le meilleur choix. Et ne l’utilisez jamais comme couche de sécurité. Gardez-le dans sa voie, sa représentation et son transport, et Base64 est un outil fiable et universel.