Base 64 Encodage : Guide Complet Développeur 2026

Pendant un audit technique l’an dernier, un détail banal m’a sauté aux yeux : un développeur junior avait implémenté l’encodage Base 64 en pensant qu’il s’agissait d’une méthode de chiffrement. Résultat, des identifiants « protégés » en Base 64 dans des paramètres d’URL, visibles et décodables par n’importe qui en trois secondes. Cet article existe pour clarifier ce que Base 64 fait réellement, et pourquoi le confondre avec du chiffrement est une erreur qui revient sans cesse.

Ce qu’est réellement l’encodage Base 64

Base 64 est un système de représentation de données binaires sous forme de texte, en utilisant un alphabet de 64 caractères (lettres majuscules, minuscules, chiffres, et deux symboles). Il a été conçu à l’origine pour transporter des données binaires (images, fichiers) dans des contextes qui n’acceptent que du texte pur — les e-mails, notamment, avant que les protocoles modernes ne gèrent nativement les pièces jointes.

Le point essentiel à comprendre : Base 64 n’est pas un chiffrement, c’est un encodage. La différence est fondamentale. Un chiffrement transforme une donnée pour la rendre illisible sans une clé secrète. Un encodage transforme simplement le format de représentation, de manière totalement réversible et publique — n’importe qui connaissant l’algorithme (documenté depuis des décennies) peut décoder une chaîne Base 64 sans clé, sans mot de passe, sans effort.

Le cas client qui illustre l’erreur

Chez un client SaaS que j’ai audité, l’équipe technique stockait des jetons de session encodés en Base 64 dans les paramètres d’URL de leur application, persuadée que cela suffisait à « masquer » les informations utilisateur. En décodant simplement la chaîne avec un outil en ligne gratuit, j’ai pu lire l’identifiant utilisateur brut et une partie de son adresse e-mail en clair. Ce n’était pas une faille de sécurité au sens strict — aucune donnée bancaire n’était exposée — mais c’était une exposition d’informations personnelles qui aurait dû être chiffrée, ou au minimum ne jamais transiter dans une URL visible et journalisée par des dizaines de systèmes intermédiaires (proxies, logs serveur, historiques de navigateur).

Où Base 64 est réellement utile

Cela ne veut pas dire que Base 64 est inutile — bien au contraire, c’est un outil précieux dans plusieurs contextes légitimes :

• Intégration d’images en ligne (data URI) : encoder une petite icône directement dans le CSS ou le HTML pour réduire le nombre de requêtes HTTP, une technique que j’utilise encore pour des favicons ou de petits pictogrammes sur des sites à fort trafic
• Transport de données binaires dans du JSON : les API qui doivent transmettre un fichier (PDF, image) dans une charge utile JSON encodent souvent ce fichier en Base 64 puisque JSON ne gère que du texte
• Jetons JWT (JSON Web Tokens) : les en-têtes et charges utiles d’un JWT sont encodés en Base 64 URL-safe — mais la sécurité du jeton repose sur sa signature cryptographique, jamais sur l’encodage lui-même
• Emails et pièces jointes : l’usage historique, toujours actif dans le protocole MIME

Guide pratique : encoder et décoder correctement

Voici la checklist que je donne à mes clients pour vérifier s’ils utilisent Base 64 correctement :

• Ne jamais utiliser Base 64 seul pour protéger une donnée sensible — toujours coupler à un vrai chiffrement (AES) si la confidentialité est requise
• Vérifier que les identifiants encodés dans une URL ne contiennent aucune information personnelle exploitable une fois décodée
• Pour un test rapide en ligne de commande : echo -n "texte" | base64 pour encoder, echo "chaîne" | base64 --decode pour décoder
• En JavaScript côté navigateur : btoa() pour encoder, atob() pour décoder (attention aux caractères accentués, qui nécessitent un encodage UTF-8 préalable)
• En Python : le module base64 avec base64.b64encode() et base64.b64decode()
• Toujours utiliser la variante « URL-safe » (remplaçant + et / par - et _) quand la chaîne encodée doit transiter dans une URL

Le cas particulier des JWT

Je reçois régulièrement des questions sur la sécurité des JSON Web Tokens, parce que leur structure (trois blocs séparés par des points, chacun encodé en Base 64 URL-safe) donne l’illusion d’un chiffrement. En pratique, n’importe qui peut coller un JWT dans un décodeur en ligne et lire l’intégralité de sa charge utile — rôles utilisateur, identifiants, parfois des scopes d’autorisation. La sécurité d’un JWT ne vient jamais de l’encodage Base 64 de son contenu, mais uniquement de sa signature (HMAC ou RSA), qui empêche la modification du jeton sans invalider la signature. J’ai vu des équipes stocker des informations qu’elles jugeaient sensibles directement dans la charge utile d’un JWT, en pensant que l’encodage suffisait à les protéger de la lecture — c’est exactement la même erreur que celle du client SaaS mentionné plus haut, transposée à un contexte différent.

Le mythe à corriger une bonne fois pour toutes

La plupart des agences digitales croient qu' »encoder, c’est sécuriser ». C’est ce mythe précis qui a conduit au problème que j’ai audité chez ce client SaaS. Encoder rend une donnée illisible pour un œil humain non averti, mais absolument pas pour quiconque sait ce qu’est Base 64 — et c’est le cas de n’importe quel développeur, de n’importe quel outil d’audit de sécurité, et même de Google lorsqu’il indexe une page contenant une chaîne Base 64 en clair dans son code source.

J’ai testé cette hypothèse directement avec Googlebot : une chaîne Base 64 contenant un mot-clé pertinent, placée dans un attribut caché d’une page, a bien été indexée en clair après décodage automatique par certains outils de scraping tiers. Autrement dit, cacher du texte en Base 64 pour « tromper » un crawler n’est pas une stratégie de camouflage fiable non plus.

Pour aller plus loin : consultez l’analyse de logs pour repérer ce type d’exposition et mon parcours en audit technique.

Avez-vous déjà vérifié ce que contiennent réellement les chaînes Base 64 qui circulent dans les URLs ou le code source de votre site ?