Base64 est l’opération pseudo-sécuritaire la plus mal utilisée que j’aie vue. Un dev backend annonce fièrement j’ai chiffré ce token avec Base64; le dev frontend hoche poliment la tête, puis l’inverse en une ligne.

Cet article existe pour que la prochaine fois que vous lisez Base64 chiffré vous puissiez dire immédiatement—ce n’est pas du chiffrement.

Résumé en 30 secondes

  • Base64 est un encodage, pas un chiffrement. Il mappe des données binaires vers 64 caractères imprimables. Quiconque voit la chaîne peut l’inverser vers les octets d’origine.
  • Une ligne pour inverser: Buffer.from(str, ‘base64’).toString() en Node.js, atob(str) dans le navigateur. Terminé.
  • Son vrai travail: faire voyager des données binaires dans des canaux qui n’acceptent que du texte—JSON, corps d’e-mail, query strings d’URL.
  • Ne sert pas à cacher des mots de passe, tokens ou clés d’API. Pour cela il vous faut du vrai chiffrement: AES, libsodium, age, GPG.

5 scénarios réels où Base64 est mal utilisé

Scénario 1: chiffrer des mots de passe dans des fichiers de config

db_password=cm9vdC1wYXNzLXdvcmQ=

Croyez-le ou non, cette chaîne décode en root-pass-word.

Pourquoi les équipes tombent dedans: les fichiers de configuration sont l’actif le plus fuité de tout dépôt. Base64 semble ajouter un mot de passe, mais quiconque a le fichier l’inverse en 5 secondes.

Le correctif: utilisez SOPS, age, Vault, ou au minimum AES-GCM. Base64 est du masquage, pas du chiffrement.

Scénario 2: JWT chiffre le payload

eyJhbG…lKxw

Le morceau du milieu est généralement Base64URL. Mettez-le dans n’importe quel décodeur JWT en ligne—ID utilisateur, expiration, scopes sont tous là.

Pourquoi les équipes tombent dedans: les signatures JWT trompent les gens en leur faisant penser invisible = sécurisé. Le payload n’est jamais chiffré; c’est explicite dans la spec JWT—signé, pas chiffré. Si vous voulez le payload chiffré, utilisez JWE.

Scénario 3: vous chiffrez votre clé d’API dans la doc

Authorization: Basic YWRtaW46cGFzc3dvcmQ=

Décode en admin:password.

Pourquoi les équipes tombent dedans: Authorization: Basic … apparaît dans les tutoriels partout; les nouveaux copient sans réaliser que le bout après Basic est juste username:password en clair encodé en Base64.

Scénario 4: cacher des IDs sensibles dans des URLs

/users/details?token=MTIzNDU2Nzg5MDEyMzQ1Ng==

Enrobez un ID interne en Base64, mettez-le dans une URL, espérez que personne ne devine la clé primaire sous-jacente.

Pourquoi les équipes tombent dedans: c’est de l’obscurité par encodage. Les chaînes Base64 ressemblent à du hash ou du chiffré, mais les IDs sont généralement des entiers séquentiels, et Base64 n’ajoute qu’une couche de devinette, pas de sécurité. Quelqu’un qui parcourt les IDs en ordre parcourt la forme encodée en ordre aussi.

Scénario 5: coller des extraits de code chiffrés dans Slack ou e-mail

Quelqu’un colle: déchiffre ça avant la prod, le secret est encodé en base64 Réponse: quoi? Expéditeur: moi, l’original était secret_api_key_here_in_plain

Je jure sur des projets ratés que ce scénario existe.

Pourquoi les équipes tombent dedans: supposant que Base64 échappe à la recherche, la copie, la capture d’écran ou l’OCR. Ce n’est pas le cas—les chaînes Base64 ont un look distinctif et sont exactement ce que les outils automatisés d’audit de trafic recherchent.

4 faits contre-intuitifs sur Base64

Fait 1: les chaînes Base64 font 33% de plus que l’original

L’encodage grossit les données. 3 octets deviennent 4 caractères Base64, donc aGVsbG8= est plus long que hello. Si vous appelez votre encodage du chiffrement et vous plaignez que la sortie est plus longue, vous avez choisi le mauvais outil.

Fait 2: Base64 n’est pas un hash

Les hashes sont à sens unique (théoriquement irréversibles), Base64 est à double sens (totalement réversible). Ce sont des outils différents pour des travaux différents. Quiconque utilise Base64 pour hasher des mots de passe et les stocke en base n’a stocké aucun hash—n’importe quel attaquant les décode directement.

Fait 3: Base64 n’est pas de la compression

C’est juste un swap de jeu de caractères. Aucune donnée n’est retirée. aGVsbG8= prend toujours ≥ les octets de hello + padding.

Fait 4: le btoa du navigateur ne supporte que Latin-1

Appeler btoa(‘你好’) lance InvalidCharacterError parce que btoa n’encode que les points de code 0–255. C’est pourquoi notre outil Text Encoder fait TextEncoder().encode() puis btoa puis TextDecoder().decode(), pour être UTF-8 safe de bout en bout.

Pratiques recommandées

  1. Protéger mots de passe / tokens / clés d’API: utilisez du vrai chiffrement. AES-256-GCM, libsodium (crypto_secretbox_easy), age, GPG—choisissez-en un, jamais Base64.
  2. Fourrer du binaire dans du JSON ou des URLs: utilisez Base64, c’est son job. L’onglet Base64 de notre outil Text Encoder utilise par défaut la chaîne UTF-8 safe, décodez aGVsbG8= et voyez hello.
  3. Transport binaire URL-safe: utilisez Base64URL (- et _ à la place de + et /, pas de padding). S’appaire avec JWT.
  4. Incorporer des images en HTML/CSS: utilisez data:image/…;base64,…—mais le HTML fait +33% et ne peut pas être caché par CDN, donc utilisez avec modération.
  5. Enseigner Base64 aux nouveaux: insistez c’est un camion de déménagement, pas un coffre. Les camions déplacent les meubles de A à B et n’importe quel déménageur peut voir le contenu; les coffres (Fort Knox) sont ce qu’il faut pour la vraie confidentialité.

Base64 est, par spec, un schéma d’encodage de caractères (RFC 4648)—juste du transport. Écrire hello puis مرحبا puis hello à nouveau est pur mouvement sans signification de sécurité. Si vous avez besoin de sécurité, vous avez besoin de vraies primitives cryptographiques.

Essayez notre outil Text Encoder, passez à l’onglet Base64, collez n’importe quelle chaîne et encodez/décodez instantanément—voyez la différence encodage-vs-chiffrement en une seconde. Si vous voulez comparer aux hashes (HMAC, SHA-256), voyez notre crypto-tools.