Base64 ne fournit pas de secret. Toute personne recevant la valeur codée peut récupérer ses octets sans mot de passe ni clé. Cacher les informations d'identification dans une longue chaîne modifie leur apparence, mais pas celui qui peut les lire. Appliquez les mêmes règles de traitement aux secrets codés qu'aux originaux.
L'encodage, le cryptage et les signatures répondent à différentes questions
L'encodage demande comment les octets peuvent voyager dans un système orienté texte. Le cryptage protège la confidentialité sous une clé cryptographique. Une étiquette d'authentification ou une signature numérique peut établir que les données ont été produites par une partie autorisée et n'ont pas été modifiées, à condition que le processus de vérification et les clés soient corrects. Une simple somme de contrôle permet principalement de détecter une corruption accidentelle. Aucune de ces garanties ne découle de Base64 seul.
Un JWT décodé est un exemple utile. Son en-tête et sa charge utile sont des structures lisibles, mais leur lecture ne vérifie pas la signature, l'émetteur, l'audience ou la politique d'expiration. Traitez une réclamation non vérifiée comme une entrée non fiable. Ne laissez pas le JSON formaté d'un téléspectateur devenir une décision d'autorisation.
Gardez le contenu décodé inerte
Une charge utile peut décoder en HTML, JavaScript, un SVG contenant du contenu actif ou un document mal formé. Afficher le texte avec textContent, non innerHTML. N'exécutez pas de code décodé et n'insérez pas de SVG arbitraire dans votre page. Une donnée déclarée de type URI MIME est fournie par l'expéditeur et peut être fausse. Les signatures de fichiers aident à identifier un format probable, mais un en-tête correspondant n'établit pas qu'un fichier est complet ou sûr.
// decodedText comes from an untrusted payload.
const output = document.createElement('pre');
output.textContent = decodedText;
document.body.append(output); // displays markup as textFixer des limites avant d'allouer de la mémoire
Le texte codé développe les données et un navigateur peut contenir la chaîne d'entrée, les octets décodés et un aperçu en même temps. Appliquez des limites avant le décodage, limitez les types de documents acceptés et laissez les utilisateurs annuler les opérations longues. Une entrée mal formée doit produire un état d'erreur distinct au lieu d'une sortie qui peut être copiée comme s'il s'agissait de données réussies.
Pour les travaux sensibles, inspectez le comportement réseau et la politique de rétention de l’outil. Le traitement du navigateur et le traitement du serveur API ont des limites différentes. Évitez de placer des jetons dans les URL des pages, où ils peuvent accéder à l'historique du navigateur, aux captures d'écran ou aux journaux d'accès. Lors des tests, utilisez des données synthétiques avec la même structure. RFC 4648 discute des ambiguïtés d'encodage ; la sécurité d’un protocole plus vaste dépend toujours de sa conception complète.