Le stockage local est une API de stockage Web permettant aux sites web de stocker des paires clé-valeur dans un navigateur sans date d'expiration. Bien que pratique pour la persistance des données côté client, il nécessite une réflexion approfondie en matière de sécurité, car les données stockées sont accessibles à tout JavaScript exécuté sur l'origine. Les données sensibles doivent être cryptées et les entrées doivent être validées afin d'éviter toute attaque XSS.
Le Local Storage est une API Web Storage qui permet à un site de conserver des paires clé-valeur sous forme de chaînes dans le navigateur, sans date d'expiration et cantonnées à une seule origine (protocole, hôte et port). Les données écrites par pages.example.com ne sont lisibles que par cette même origine, et elles survivent à la fermeture des onglets, aux rechargements de page et aux redémarrages du navigateur jusqu'à ce que le code ou l'utilisateur les efface. L'accès se fait de manière synchrone via window.localStorage, si bien que les lectures et les écritures bloquent le thread principal et que la limite de taille pratique tourne autour de 5 à 10 Mo par origine. Contrairement aux cookies, le contenu ne voyage jamais avec les requêtes HTTP, ce qui garde les en-têtes de requête légers, mais signifie aussi que le serveur ne voit ni ne contrôle jamais ce qu'une page y stocke.
La propriété critique est que n'importe quel JavaScript s'exécutant sur l'origine peut lire chaque clé du Local Storage. Il n'existe aucun équivalent à HttpOnly, de sorte qu'une seule faille de cross-site scripting, ou un unique script tiers compromis, peut énumérer le stockage et exfiltrer tout ce qu'il y trouve. Pour cette raison, des jetons de session, des JWT, des clés d'API ou des données personnelles stockés ici sont bien plus exposés que la même valeur placée dans un cookie HttpOnly, qu'un script ne peut pas lire. Les valeurs persistent également indéfiniment, si bien qu'un jeton volé des semaines après la connexion peut rester valide. Le Local Storage n'offre aucun chiffrement, aucun contrôle d'intégrité et aucune expiration automatique, ce qui en fait un mauvais coffre-fort pour tout ce qu'un attaquant pourrait convoiter.
Considérez le Local Storage comme public pour n'importe quel code présent sur la page. Conservez les jetons d'authentification dans des cookies HttpOnly, Secure et SameSite plutôt que dans un stockage que le JavaScript peut lire, et n'y stockez localement que des données non sensibles et de faible valeur. Nettoyez et validez tout ce que vous relisez avant de l'insérer dans le DOM, car des valeurs contrôlées par un attaquant et récupérées depuis le stockage peuvent déclencher un XSS basé sur le DOM. Une Content Security Policy stricte limite les scripts autorisés à s'exécuter, et donc qui peut toucher au stockage. cside intervient sur le volet des scripts tiers : en faisant transiter les scripts externes par un méthode Script et en analysant la charge utile, il peut détecter et bloquer un script fournisseur qui se met à lire le stockage et à l'exfiltrer.
Pas pour les secrets. Le Local Storage n'est jamais envoyé avec les requêtes, ce qui évite une partie de l'exposition au CSRF, mais chaque script de l'origine peut le lire, et il ne peut pas être marqué HttpOnly. Un cookie HttpOnly est invisible pour le JavaScript, donc pour les jetons de session un cookie bien configuré est le choix le plus sûr.
Non. Le Local Storage est cloisonné par origine complète, si bien que app.example.com et shop.example.com disposent de stockages distincts et isolés et ne peuvent pas lire les données l'un de l'autre. Les cookies peuvent être partagés entre sous-domaines via l'attribut de domaine, mais le Local Storage n'a aucun mécanisme équivalent.
We answer client-side security questions every day. Bring yours.