Sécurité : ce qu’il ne faut jamais stocker

localStorage et sessionStorage enregistrent les données sans chiffrement sur le disque, dans le profil de l’utilisateur. Tout processus ayant accès au système de fichiers, notamment un logiciel malveillant, un outil de sauvegarde ou un autre utilisateur connecté, peut lire toutes les valeurs stockées sans passer par le navigateur.

Tous les scripts exécutés sur l’origine partagent le même espace de stockage. Une attaque XSS réussie, un SDK tiers compromis ou une extension de navigateur malveillante peut appeler localStorage.getItem et exfiltrer toutes les valeurs stockées. Il n’existe aucune isolation entre les scripts.

Ne placez pas de jetons de session, de JWT, de jetons d’actualisation ni de clés d’interface de programmation dans localStorage. Si un attaquant injecte une seule ligne de JavaScript, le jeton est immédiatement divulgué. Utilisez des cookies httpOnly, Secure et SameSite afin que le jeton ne soit jamais accessible depuis JavaScript.

Stocker des mots de passe sous quelque forme que ce soit — en clair, hachés ou chiffrés — est incorrect côté client. Le hachage côté client n’aide pas lorsque l’attaquant peut lire le hachage et le réutiliser. La gestion des mots de passe doit être entièrement effectuée sur le serveur avec un hachage dédié, comme bcrypt.

PCI-DSS interdit de stocker les numéros de carte, les codes CVV, les données de bande magnétique ou les dates d’expiration dans le stockage côté client. Utilisez plutôt un prestataire de paiement utilisant la tokenisation (Stripe, Braintree, Adyen), qui renvoie un jeton à durée de vie courte associé à votre origine.

Les pièces d’identité officielles, les dates de naissance complètes, les adresses personnelles et les données médicales attirent les autorités de contrôle (GDPR, HIPAA) ainsi que les attaquants. Ne stockez que ce qui est nécessaire pour la session en cours, redemandez ces informations lorsque cela est nécessaire et laissez le serveur conserver la source de vérité.

Une faille XSS qui divulgue document.cookie est grave. La même faille sur une page qui stocke des jetons dans localStorage remet à l’attaquant toutes les valeurs stockées en une seule fois. Considérez localStorage comme une surface où « la compromission d’un script compromet tout ».

Chiffrer des valeurs avec une clé qui se trouve également dans JavaScript n’offre aucune protection réelle : l’attaquant capable de lire le texte chiffré peut aussi lire la clé. Les véritables secrets doivent rester côté serveur et être réémis, jamais conservés côté client.

Les préférences de l’interface utilisateur (thème, barre latérale réduite, langue), les indicateurs de fonctionnalité non sensibles, le contenu de formulaires en brouillon et l’état temporaire d’un assistant peuvent tous être stockés sans problème. Ils sont de toute façon visibles par l’utilisateur, et leur divulgation ne permet pas de prendre le contrôle d’un compte.

Fournissez l’authentification via Set-Cookie: token=...; HttpOnly; Secure; SameSite=Strict. L’attribut HttpOnly rend le cookie inaccessible à JavaScript, ce qui neutralise la plupart des charges utiles XSS qui dérobent des jetons, même si d’autres failles existent sur la page.

Si vous devez mettre en cache des données apparemment sensibles, limitez strictement leur portée (TTL court, effacement à la déconnexion, suppression à la fermeture de l’onglet via sessionStorage), appliquez une politique stricte de sécurité du contenu pour bloquer les scripts injectés et vérifiez chaque script tiers exécuté sur les pages authentifiées.

Web Storage est en texte brut, lisible par les scripts et partagé par origine. Ne placez jamais de jetons d’authentification, de mots de passe, de données de paiement ou d’informations personnelles réglementées à cet endroit. Conservez les secrets dans des cookies httpOnly et réservez localStorage à l’état inoffensif de l’interface utilisateur, que l’utilisateur pourrait de toute façon voir.