Base64 Encoding: When to Use It and When Not To

Il y a trois ans, j'ai vu un développeur junior de mon équipe encoder un fichier vidéo de 50 Mo entier en Base64 et l'incorporer directement dans une réponse API JSON. L'application a calé. Les utilisateurs se plaignaient de temps de chargement d'une minute. Nos coûts de CDN ont triplé du jour au lendemain. Quand je lui ai demandé pourquoi il avait fait cela, il a dit : "J'ai lu que Base64 rend les données sûres pour la transmission sur Internet."

Il n'avait pas tout à fait tort, mais il n'avait pas raison non plus. Cet incident nous a coûté environ 12 000 $ en mise à l'échelle d'urgence de l'infrastructure et environ 200 heures de temps de développement pour le refactoriser. Cela m'a également appris quelque chose d'important : l'encodage Base64 est l'une de ces technologies qui semblent simples en surface mais qui sont totalement mal comprises dans la pratique.

Je suis Marcus Chen, et j'ai passé les 14 dernières années à construire des applications intensives en données—d'abord dans une société de services financiers traitant des millions de transactions par jour, puis dans une startup de santé traitant des données sensibles de patients, et maintenant en tant qu'ingénieur principal dans une société SaaS servant plus de 50 000 entreprises. Pendant ce temps, j'ai vu Base64 utilisé de manière brillante et catastrophique, souvent dans le même code.

Cet article est ma tentative de remettre les pendules à l'heure. Je vais expliquer ce que Base64 fait réellement, quand c'est l'outil approprié pour la tâche, quand cela ne l'est absolument pas, et comment prendre des décisions éclairées qui ne vous hanteront pas à 3 heures du matin lorsque votre application est en train de s'effondrer.

Ce que Base64 fait réellement (et ce qu'il ne fait pas)

Commençons par les fondamentaux, car j'ai constaté que la plupart des abus de Base64 viennent de conceptions erronées fondamentales sur ce qu'il est.

Base64 est un schéma d'encodage qui convertit les données binaires en texte ASCII en utilisant 64 caractères imprimables (A-Z, a-z, 0-9, +, et /). C'est tout. Ce n'est pas un cryptage. Ce n'est pas une compression. Ce n'est pas une mesure de sécurité. C'est un mécanisme de traduction—comme convertir un livre du français vers l'anglais. Le contenu ne change pas ; seule la représentation change.

Voici ce qui se passe sous le capot : Base64 prend chaque trois octets de données d'entrée (24 bits) et les représente sous forme de quatre caractères ASCII (32 bits). Cela signifie que vos données augmentent d'environ 33 % après l'encodage. Un fichier de 1 Mo devient environ 1,33 Mo. Une sauvegarde de base de données de 100 Mo devient 133 Mo. Cette surcharge n'est pas triviale, et c'est la première chose que les gens oublient lorsqu'ils se tournent vers Base64.

La raison pour laquelle Base64 existe est historique. Dans les débuts d'Internet, de nombreux systèmes ne pouvaient gérer de manière fiable que le texte ASCII à 7 bits. Les données binaires—images, exécutables, fichiers compressés—devenaient corrompues lorsqu'elles étaient transmises par des serveurs de messagerie, stockées dans des bases de données conçues pour le texte, ou transférées à travers des systèmes qui interprétaient certaines valeurs d'octets comme des caractères de contrôle. Base64 a résolu ce problème en s'assurant que les données binaires pouvaient se faire passer pour du texte brut et survivre à ces parcours intacts.

Je me souviens d'avoir travaillé sur un ancien système de messagerie en 2012 qui corrompait silencieusement tout message contenant des octets avec des valeurs supérieures à 127. Nous devions encoder tous les fichiers joints en Base64 juste pour les faire passer dans le pipeline. Mais : la plupart des systèmes modernes n'ont plus cette limitation. HTTP peut gérer les données binaires sans problème. Les bases de données modernes ont des types BLOB. Les systèmes de fichiers ne se soucient pas de savoir si vos données sont du texte ou binaires.

Cependant, les développeurs continuent d'utiliser Base64 comme si nous étions encore en 1996. Pourquoi ? Parce que c'est facile, c'est familier, et cela semble fonctionner—jusqu'à ce que cela ne fonctionne pas.

Quand Base64 est vraiment le bon choix

Malgré mes récits d'avertissement, Base64 n'est pas intrinsèquement mauvais. Il existe des scénarios légitimes et bien raisonné où c'est exactement le bon outil. Laissez-moi vous les expliquer.

"Base64 est un mécanisme de traduction, pas une mesure de sécurité. Le traiter comme un cryptage est comme penser qu'un traducteur de langue rend vos secrets sûrs—ce n'est pas le cas, cela les rend simplement lisibles dans un alphabet différent."

Le cas d'utilisation valide le plus commun est d'incorporer de petits actifs binaires directement dans des formats basés sur du texte. Les URIs de données dans CSS et HTML en sont un parfait exemple. Si vous avez une icône de 2 Ko qui apparaît sur chaque page de votre application, l'incorporer comme une URI de données Base64 peut en fait améliorer les performances en éliminant une requête HTTP. Le calcul est simple : la surcharge de la requête HTTP (généralement 50 à 200 ms y compris la recherche DNS, l'établissement de la connexion et le traitement du serveur) dépasse le coût de transfert de 667 octets supplémentaires (la surcharge de 33 % sur 2 Ko).

J'utilise cette technique de manière intensive pour des actifs critiques au-dessus de la pliure. Dans un projet, nous avons réduit notre temps de rendu de page initial de 1,2 seconde à 0,8 seconde en encodant en Base64 cinq petites icônes SVG (totalisant 8 Ko) directement dans notre CSS critique. Les 2,6 Ko de surcharge supplémentaires ont été plus que compensés par l'élimination de cinq requêtes HTTP distinctes.

Un autre cas d'utilisation légitime est le stockage de données binaires dans des systèmes qui ne supportent réellement que le texte. JSON est l'exemple évident. JSON n'a pas de type binaire natif, donc si vous devez inclure des données binaires dans une charge utile JSON—par exemple, une petite image miniature dans une réponse API—Base64 est votre seule option. Mais remarquez que j'ai dit "petite". J'ai une règle stricte : ne jamais encoder en Base64 quelque chose de plus grand que 50 Ko pour inclusion dans JSON. Au-delà de ce seuil, vous devriez utiliser des requêtes multiparties, des points de terminaison séparés, ou des protocoles binaires directs.

Les jetons d'authentification et les opérations cryptographiques sont un autre domaine valide. Les JWT (JSON Web Tokens) utilisent un encodage Base64URL pour leurs sections d'en-tête et de charge utile. Cela a du sens parce que les JWT doivent être transmis dans les en-têtes HTTP et les URL, qui sont tous deux des contextes basés sur le texte. Les jetons sont généralement petits (moins de 2 Ko), et la surcharge de 33 % est acceptable compte tenu de la commodité de pouvoir les passer sous forme de chaînes simples.

J'utilise également Base64 lors de la génération d'identifiants uniques qui doivent être sécurisés pour les URL et plus compacts que l'hexadécimal. Un UUID de 128 bits codé en hexadécimal fait 32 caractères ; le même UUID en Base64 ne fait que 22 caractères. Lorsque vous générez des millions d'ID et que vous les stockez dans des index de base de données, cette économie d'espace de 31 % s'accumule. Dans un système que j'ai créé, le passage de l'encodage hexadécimal à Base64URL pour nos clés primaires a réduit notre taille d'index de 180 Go à travers notre cluster.

Le coût de performance dont personne ne parle

Parlons chiffres, parce que je constate que les avertissements abstraits concernant "la surcharge de performance" ne fonctionnent pas. Les mesures concrètes oui.

J'ai réalisé une série de tests de performance sur un serveur d'application typique (4 cœurs Intel Xeon, 16 Go de RAM) en encodant et décodant divers fichiers. Encoder un fichier de 10 Mo en Base64 a pris en moyenne 42 millisecondes. Le décoder a pris 38 millisecondes. Cela peut ne pas sembler beaucoup, mais considérez : si vous encodez des images téléchargées par les utilisateurs à chaque requête, et que vous traitez 100 requêtes par seconde, vous dépensez 4,2 secondes de temps CPU par seconde juste pour l'encodage Base64. C'est plus d'un cœur CPU complet dédié uniquement à la surcharge d'encodage.

L'impact sur la mémoire est encore pire. Parce que l'encodage Base64 nécessite de mettre en mémoire tampon l'intégralité de l'entrée et de la sortie simultanément, encoder ce fichier de 10 Mo nécessite en réalité environ 23 Mo de mémoire.