Qu'est-ce que localStorage et sessionStorage ?

localStorage et sessionStorage sont deux mécanismes fournis par l'API Web Storage, un standard intégré à tous les navigateurs modernes. Ils permettent aux sites web de stocker des paires clé-valeur directement dans le navigateur du visiteur, sans impliquer le serveur à chaque chargement de page. Si vous avez déjà activé le mode sombre sur un site web et constaté que votre préférence était toujours là le lendemain, il y a de fortes chances que le site ait enregistré ce choix dans localStorage.

Comment fonctionne l'API Web Storage

L'API Web Storage est intentionnellement simple. Vous appelez localStorage.setItem('key', 'value') pour écrire des données, localStorage.getItem('key') pour les lire et localStorage.removeItem('key') pour les supprimer. sessionStorage utilise exactement les mêmes méthodes. Les deux stockages n'acceptent que des chaînes de caractères, donc les objets sont généralement sérialisés avec JSON.stringify() avant d'être enregistrés. Il n'y a pas de langage de requête, pas d'indexation et pas de structure relationnelle. Il s'agit d'un magasin clé-valeur plat conçu pour des lectures et écritures rapides et légères.

localStorage vs sessionStorage : différences clés

• Persistance : Les données de localStorage restent dans le navigateur jusqu'à ce que l'utilisateur ou le site les supprime explicitement. Il n'y a pas de date d'expiration. Les données de sessionStorage, en revanche, sont effacées au moment où l'onglet du navigateur est fermé.
• Portée entre onglets : localStorage est partagé entre tous les onglets et fenêtres qui appartiennent à la même origine (protocole + domaine + port). sessionStorage est isolé à un seul onglet. Si vous ouvrez la même page dans deux onglets, chaque onglet a son propre sessionStorage.
• Limites de stockage : Les deux offrent généralement de 5 à 10 Mo par origine, selon le navigateur. Chrome et Firefox utilisent par défaut environ 5 Mo par origine pour chaque magasin. Safari peut être plus strict, en particulier en mode de navigation privée, où il limite parfois le stockage à seulement quelques centaines de kilo-octets.
• Comportement réseau : Ni localStorage ni sessionStorage ne sont envoyés au serveur avec les requêtes HTTP. C'est la différence fondamentale avec les cookies, qui sont attachés automatiquement à chaque en-tête de requête.

Ce que les sites WordPress stockent couramment

Les extensions et thèmes WordPress utilisent le stockage navigateur pour une grande variété d'objectifs. Voici les plus courants :

• Préférences de thème : Bascule du mode sombre, état de la barre latérale réduite/étendue, choix de la taille de police. Ces données sont presque toujours stockées dans localStorage car elles doivent survivre à la fermeture d'un onglet.
• Données de panier : WooCommerce et des extensions similaires mettent parfois en cache des fragments de panier dans localStorage pour éviter des allers-retours supplémentaires avec le serveur lors de l'affichage du mini-panier dans l'en-tête.
• Brouillons de formulaire : Les extensions de formulaires de contact peuvent enregistrer automatiquement la saisie de l'utilisateur dans sessionStorage afin qu'un formulaire partiellement rempli ne soit pas perdu si l'utilisateur navigue accidentellement ailleurs et revient via le bouton précédent.
• Choix de consentement aux cookies : Certaines extensions de bannière de consentement (comme Complianz ou CookieYes) stockent l'état de consentement du visiteur dans localStorage plutôt que dans un cookie, bien que l'utilisation d'un cookie soit plus courante.
• État de l'interface admin : Le tableau de bord d'administration WordPress lui-même utilise les deux mécanismes de stockage. Par exemple, il se souvient des metaboxes réduites, des colonnes visibles dans la liste des articles et de l'état du menu d'administration.
• Tampons d'analyse et de suivi : Certains scripts d'analyse regroupent les événements dans localStorage et les envoient au serveur par lots pour réduire les requêtes réseau.

Considérations de sécurité

Web Storage est pratique, mais il s'accompagne de réels compromis de sécurité que les développeurs doivent comprendre.

• Exposition au XSS : Tout JavaScript s'exécutant sur la page peut lire localStorage et sessionStorage. Si un attaquant parvient à injecter un script via une vulnérabilité cross-site scripting (XSS), il peut extraire toutes les valeurs stockées. Les cookies peuvent être protégés avec le drapeau HttpOnly, qui bloque entièrement l'accès JavaScript. Il n'existe pas de protection équivalente pour Web Storage.
• Politique de même origine : Le stockage est limité à l'origine, ce qui signifie que https://example.com ne peut pas lire le stockage de https://other.com. Cependant, tout script de la même origine, y compris les scripts tiers que vous chargez (analyse, régies publicitaires, widgets de chat), a un accès complet au même stockage.
• Pas de chiffrement : Les données sont stockées en clair sur le disque. Toute personne ayant un accès physique à l'appareil, ou un logiciel malveillant s'exécutant sur l'appareil, peut les lire. Ne stockez jamais de mots de passe, de jetons ou d'autres identifiants sensibles dans Web Storage.
• Pas de validation côté serveur : Comme les données ne vivent que dans le navigateur, un utilisateur ou un script peut les modifier librement. Ne vous fiez jamais aux valeurs de Web Storage pour des décisions d'autorisation ou de sécurité côté serveur.

RGPD et implications en matière de confidentialité

En vertu du RGPD et de la directive ePrivacy, localStorage et sessionStorage sont traités de la même manière que les cookies en ce qui concerne les exigences de consentement. Le principe juridique est neutre sur le plan technologique : si vous stockez ou lisez des informations sur l'appareil d'un utilisateur dans un but qui n'est pas strictement nécessaire au service que l'utilisateur a demandé, vous avez besoin d'un consentement. Cela signifie qu'un panier WooCommerce stocké dans localStorage est probablement « strictement nécessaire » et ne nécessite pas de consentement. Mais un identifiant d'analyse stocké dans localStorage pour suivre les visiteurs récurrents en a absolument besoin. De nombreux propriétaires de sites négligent cela parce que les outils de consentement aux cookies se concentrent traditionnellement sur les cookies, mais les régulateurs ont clairement indiqué que les règles s'appliquent à toutes les technologies de stockage côté client.

Web Storage vs cookies : quand utiliser lequel

• Utilisez les cookies : lorsque le serveur a besoin de lire la valeur à chaque requête (identifiants de session, jetons d'authentification), lorsque vous avez besoin de la protection HttpOnly contre le XSS, ou lorsque vous avez besoin d'un contrôle d'expiration précis.
• Utilisez localStorage : lorsque vous devez conserver les préférences côté client ou mettre en cache des données entre les sessions, que les données n'ont pas besoin d'être transmises au serveur et qu'elles ne sont pas sensibles.
• Utilisez sessionStorage : lorsque les données ne doivent vivre que pendant la durée d'une seule session d'onglet, comme la progression d'un assistant de formulaire, l'état temporaire de l'interface utilisateur ou les jetons de redirection à usage unique.

Comparaison de performance

La lecture et l'écriture dans Web Storage sont synchrones et se produisent sur le thread principal. Pour de petites quantités de données, cela est rapide, généralement moins d'une milliseconde. Mais si une page écrit ou lit de grands volumes de données à chaque interaction, cela peut provoquer des saccades. Les cookies, en revanche, ajoutent de la surcharge d'une autre manière : ils augmentent la taille de chaque en-tête de requête HTTP, ce qui ralentit chaque appel réseau. Pour stocker une poignée de petites valeurs, les deux approches fonctionnent bien. Pour des ensembles de données plus importants (des dizaines de Ko ou plus), envisagez IndexedDB, qui est asynchrone et ne bloque pas le thread principal.

Comment inspecter le stockage dans les DevTools

Tous les principaux navigateurs vous permettent d'inspecter Web Storage. Dans Chrome, ouvrez les DevTools (F12), allez dans l'onglet Application et cherchez « Local Storage » et « Session Storage » dans la barre latérale gauche. Vous pouvez voir chaque paire clé-valeur, modifier manuellement les valeurs et supprimer des entrées. Firefox dispose d'un panneau similaire sous l'onglet Stockage. C'est le moyen le plus simple de voir exactement ce qu'un site WordPress stocke dans votre navigateur et de résoudre les comportements inattendus.

Ce que InspectWP vérifie

InspectWP liste toutes les entrées localStorage et sessionStorage définies par votre site WordPress lors de l'exploration. Cela vous donne une image claire de ce que votre site stocke côté client, des extensions qui en sont responsables et de la possibilité que certaines entrées soulèvent des préoccupations en matière de confidentialité au regard du RGPD ou des règles ePrivacy.