Réponse rapide : SessionStorage et localStorage sont tous deux des API de stockage web basées sur le navigateur qui permettent aux sites web de stocker des données sur l'appareil d'un utilisateur, mais ils diffèrent de manière critique en termes de persistance et de portée. localStorage conserve les données indéfiniment à travers les sessions et les onglets, tandis que sessionStorage efface les données lorsque l'onglet du navigateur se ferme. Du point de vue de la confidentialité, localStorage présente un risque nettement plus élevé car les données persistent sans expiration, ce qui en fait une cible plus attrayante pour le suivi, le fingerprinting et l'examen réglementaire dans le cadre de réglementations comme le GDPR.
Points clés à retenir
- localStorage persiste indéfiniment jusqu'à ce qu'il soit explicitement effacé ; sessionStorage est supprimé lorsque l'onglet ou la fenêtre se ferme.
- Les deux types de stockage sont vulnérables aux attaques par script intersite (XSS) et n'offrent aucun chiffrement intégré.
- Ni les données localStorage ni sessionStorage ne sont transmises automatiquement au serveur, contrairement aux cookies, mais les deux sont entièrement lisibles par tout JavaScript s'exécutant sur la même origine.
- Les scripts tiers chargés sur une page peuvent accéder aux données localStorage s'ils s'exécutent dans le même contexte d'origine.
- En vertu du GDPR, le stockage de données non essentielles dans localStorage sans le consentement de l'utilisateur est une violation de la conformité, au même titre que le dépôt de cookies de suivi.
- Les données sensibles telles que les jetons d'authentification, les mots de passe et les informations personnellement identifiables (PII) ne doivent jamais être stockées dans l'un ou l'autre mécanisme sans couches de sécurité supplémentaires.
- La navigation privée/incognito limite la persistance de localStorage mais n'élimine pas les risques de sessionStorage au sein d'une session.
- Les développeurs doivent préférer sessionStorage pour l'état temporaire, les sessions côté serveur ou les cookies HttpOnly pour l'authentification, et une plateforme de gestion du consentement telle que Biscotti CMP pour gérer le consentement au stockage.
Quelle est la différence entre SessionStorage et LocalStorage ?
SessionStorage et localStorage font tous deux partie de l'API de stockage web HTML5, mais ils servent des objectifs distincts définis par leur persistance et leur comportement de portée d'onglet.
localStorage stocke des paires clé-valeur sans date d'expiration. Les données survivent aux redémarrages du navigateur, aux redémarrages du système et aux périodes d'inactivité indéfinies jusqu'à ce que l'utilisateur ou l'application les supprime explicitement. Elles sont partagées entre tous les onglets et fenêtres fonctionnant sous la même origine (protocole + domaine + port). [1][5]
sessionStorage stocke les données uniquement pendant la durée de vie de la session de la page. Lorsque l'utilisateur ferme l'onglet ou la fenêtre, les données disparaissent. Il est important de noter que chaque onglet maintient son propre sessionStorage isolé ; l'ouverture de la même URL dans un deuxième onglet ne partage pas les données sessionStorage du premier onglet. [1]
| Caractéristique | localStorage | sessionStorage |
|---|---|---|
| Persistance | Indéfinie | Durée de vie de l'onglet/fenêtre uniquement |
| Partagé entre les onglets | Oui (même origine) | Non (isolation par onglet) |
| Survient au rechargement de la page | Oui | Oui |
| Survient à la fermeture de l'onglet | Oui | Non |
| Capacité de stockage | ~5-10 Mo par origine | ~5-10 Mo par origine |
| Transmission au serveur | Non | Non |
| Protection HttpOnly | Non disponible | Non disponible |
Les deux API respectent la politique de même origine, de sorte qu'une page sur https://example.com ne peut pas lire le stockage défini par https://otherdomain.com. [4]
localStorage présente-t-il des risques pour la vie privée par rapport à sessionStorage ?
Oui, localStorage présente des risques pour la vie privée significativement plus élevés que sessionStorage, principalement en raison de sa persistance indéfinie et de son accessibilité inter-onglets.
Les données écrites dans localStorage peuvent s'accumuler pendant des mois ou des années sans que l'utilisateur n'en ait conscience. Les annonceurs et les fournisseurs d'analyse ont historiquement utilisé localStorage comme un "super-cookie", un identifiant de suivi qui survit à la suppression des cookies car la plupart des utilisateurs ne pensent pas à effacer manuellement le stockage du navigateur. sessionStorage, en revanche, s'autodétruit à la fermeture de l'onglet, ce qui en fait un vecteur de suivi beaucoup moins utile.
Facteurs de risque de confidentialité clés uniques à localStorage :
- Identifiants de suivi persistants : Un identifiant unique stocké dans localStorage peut suivre un utilisateur sur plusieurs visites sans aucun cookie côté serveur.
- Fuite de données inter-onglets : Tout script s'exécutant dans n'importe quel onglet de la même origine peut lire toutes les données localStorage.
- Diffusion d'événements de stockage : Les modifications apportées à localStorage déclenchent un événement
storagedans d'autres onglets ouverts de la même origine, permettant une synchronisation des données inter-onglets que les utilisateurs ne peuvent pas observer. [5] - Pas d'expiration automatique : Contrairement aux cookies, qui prennent en charge les attributs
Max-AgeetExpires, localStorage n'a pas de mécanisme TTL.
Les sites web peuvent-ils suivre les utilisateurs à l'aide de localStorage et sessionStorage ?
Les sites web peuvent et utilisent localStorage pour un suivi persistant. sessionStorage est moins utile pour le suivi mais présente toujours des risques de surveillance au sein de la session.
Une seule ligne JavaScript, localStorage.setItem('uid', 'abc123'), crée un identifiant persistant qui survit à la suppression des cookies. Cette technique, parfois appelée "evercookie" ou respawn basé sur le stockage, a été documentée dans la recherche sur la confidentialité et est la raison pour laquelle les régulateurs traitent de plus en plus localStorage selon les mêmes règles de consentement que les cookies.
sessionStorage peut suivre le comportement au sein d'une seule session (flux de page, entrées de formulaire, modèles de navigation), mais ces données disparaissent lorsque l'onglet se ferme, ce qui limite son utilité pour le profilage à long terme.
Combien de temps les données restent-elles dans SessionStorage vs. LocalStorage ?
Les données localStorage restent jusqu'à ce qu'elles soient explicitement supprimées, soit par l'utilisateur qui efface le stockage du navigateur, soit par le site web qui appelle localStorage.removeItem() ou localStorage.clear(), soit par le navigateur qui applique des quotas de stockage. [2]
Les données sessionStorage sont supprimées automatiquement lorsque l'onglet ou la fenêtre qui les a créées est fermé. Elles survivent aux rechargements de page au sein du même onglet mais ne sont pas transférées vers de nouveaux onglets, même si l'utilisateur duplique l'onglet dans certains navigateurs. [1]
Implication pratique : Si un développeur stocke un jeton de session dans localStorage au lieu de sessionStorage, ce jeton reste sur l'appareil après que l'utilisateur se soit déconnecté, à moins que l'application ne le supprime explicitement. C'est une erreur courante et lourde de conséquences.
SessionStorage est-il plus privé que localStorage ?
Pour la plupart des cas d'utilisation liés à la confidentialité, oui, sessionStorage est le choix le plus respectueux de la vie privée. Sa suppression automatique à la fermeture de l'onglet signifie que les données ne persistent pas, ce qui réduit l'exposition due au partage d'appareils, aux appareils volés ou à l'analyse forensique.
Cependant, sessionStorage n'est pas intrinsèquement "privé". Au sein d'une session active, il est tout aussi vulnérable aux attaques XSS que localStorage. Tout script injecté peut appeler sessionStorage.getItem() et exfiltrer des données en temps réel. [3]
Choisissez sessionStorage si : les données ne sont nécessaires que pour l'interaction utilisateur actuelle (par exemple, l'état d'un formulaire en plusieurs étapes, les jetons de navigation à usage unique).
Choisissez localStorage si : les données doivent réellement persister entre les sessions (par exemple, les préférences d'interface utilisateur, les paramètres non sensibles), et assurez-vous qu'elles ne contiennent rien d'identifiable personnellement.
Quelles données personnelles ne devraient jamais être stockées dans localStorage ?
Les catégories de données suivantes ne devraient jamais être stockées dans localStorage (et devraient être traitées avec une extrême prudence même dans sessionStorage) : [3]
- Jetons d'authentification (JWT, jetons OAuth, ID de session)
- Mots de passe ou hachages de mots de passe
- Informations de carte de crédit ou de paiement
- Numéros d'identification émis par le gouvernement ou numéros de sécurité sociale
- Noms complets combinés à des adresses e-mail ou des numéros de téléphone
- Dossiers médicaux ou de santé
- Toute donnée classée comme "catégorie spéciale" en vertu du GDPR (données biométriques, données de santé, opinions politiques)
Les données stockées dans localStorage et sessionStorage ne sont pas chiffrées par défaut. Toute personne ayant un accès physique à l'appareil, ou tout script capable de s'exécuter sur la page, peut les lire en texte clair. [3]
Les scripts tiers peuvent-ils accéder aux données localStorage ?
Les scripts tiers peuvent accéder aux données localStorage s'ils sont chargés et exécutés dans la même origine que la page hôte. Il s'agit d'un risque critique et souvent sous-estimé.
Lorsqu'un site web intègre un script d'analyse ou de publicité tiers via une balise <script>, ce script s'exécute dans le contexte d'origine de la page hôte. Il peut lire et écrire librement dans le localStorage du site. La politique de même origine ne protège pas contre les scripts inclus intentionnellement ou par inadvertance sur la page. [4]
Ce que cela signifie en pratique : Si un site stocke un identifiant utilisateur dans localStorage et charge également un script publicitaire tiers, ce script publicitaire peut lire l'identifiant et l'associer à des données comportementales intersites, à l'insu ou sans le consentement de l'utilisateur.
C'est l'une des raisons pour lesquelles les plateformes de gestion du consentement sont importantes. Biscotti CMP permet aux sites web de gérer et de documenter le consentement de l'utilisateur pour les opérations de stockage, y compris le suivi basé sur localStorage, aidant ainsi les sites à respecter leurs obligations en vertu du GDPR et de cadres similaires.
Quelles sont les implications du GDPR concernant l'utilisation de localStorage ?
En vertu du GDPR, tout stockage de données personnelles ou d'identifiants de suivi, quel que soit le mécanisme technique, nécessite une base légale. Pour le suivi non essentiel via localStorage, cette base est presque toujours le consentement explicite de l'utilisateur. [2]
Le Comité européen de la protection des données a confirmé que localStorage utilisé à des fins d'analyse, de publicité ou de profilage d'utilisateur est soumis aux mêmes exigences de consentement que les cookies. Les sites web qui déposent des identifiants de suivi dans localStorage sans consentement préalable encourent la même exposition à l'application que ceux qui utilisent des cookies sans consentement.
Liste de contrôle de conformité pour localStorage en vertu du GDPR :
- Auditez toutes les clés localStorage écrites par les scripts propriétaires et tiers.
- Classez chaque clé : est-elle strictement nécessaire au service, ou est-elle utilisée à des fins d'analyse/publicité ?
- Pour le stockage non essentiel, subordonnez l'opération d'écriture à un consentement utilisateur documenté.
- Fournissez aux utilisateurs un mécanisme clair pour retirer leur consentement et déclencher la suppression du stockage.
- Documentez l'intérêt légitime du responsable du traitement ou l'enregistrement du consentement.
Une plateforme de gestion du consentement correctement configurée, telle que Biscotti CMP, peut automatiser une grande partie de ce cycle de vie du consentement.
localStorage peut-il être accédé sur différents sites web ?
Non. localStorage est strictement limité à l'origine (combinaison protocole + domaine + port) qui l'a créé. Un script sur https://siteA.com ne peut pas lire les données localStorage définies par https://siteB.com. [4]
Cependant, cette protection a des limites. Si un seul fournisseur de publicité ou d'analyse charge ses scripts sur siteA.com et siteB.com, chaque instance écrit dans le localStorage respectif de ce site indépendamment. Le fournisseur corrèle ensuite les données côté serveur, réalisant ainsi un suivi intersite sans violer la politique de même origine.
Comment le mode Incognito et la navigation privée affectent-ils localStorage ?
La navigation privée/incognito crée une partition de stockage temporaire qui est supprimée lorsque la fenêtre privée se ferme. localStorage écrit pendant une session incognito ne persiste pas dans le profil principal du navigateur et n'est pas accessible aux fenêtres de navigation normales.
sessionStorage se comporte de la même manière en mode incognito qu'en navigation normale : il est supprimé lorsque l'onglet se ferme.
Mises en garde importantes :
- Au sein d'une session incognito active, localStorage est toujours lisible par tous les scripts s'exécutant dans le contexte de même origine de cette session.
- Le mode incognito n'empêche pas l'exfiltration de données en temps réel basée sur XSS.
- Certains navigateurs synchronisent localStorage entre les appareils si l'utilisateur est connecté à la synchronisation du navigateur, un comportement qui peut déplacer des données "locales" vers l'infrastructure cloud.
Comment effacer SessionStorage et localStorage pour la confidentialité ?
L'effacement du stockage du navigateur est simple mais nécessite une action délibérée car les navigateurs ne le font pas automatiquement pour localStorage.
Effacement au niveau du navigateur :
- Chrome : Paramètres > Confidentialité et sécurité > Effacer les données de navigation > Images et fichiers mis en cache + Données des sites
- Firefox : Paramètres > Vie privée et sécurité > Cookies et données de sites > Effacer les données
- Safari : Réglages > Confidentialité > Gérer les données de sites web
Effacement programmatique (pour les développeurs) :
localStorage.clear()supprime toutes les clés pour l'origine.sessionStorage.clear()supprime toutes les clés pour la session d'onglet actuelle.localStorage.removeItem('keyName')supprime une clé spécifique.
Pour les utilisateurs finaux soucieux du suivi : l'effacement des "données de site" ou des "cookies et stockage" dans les paramètres du navigateur supprime le contenu de localStorage et sessionStorage pour tous les sites. Les extensions de navigateur conçues pour la confidentialité peuvent automatiser cela par site ou par session.
Quelles sont les erreurs courantes en matière de confidentialité que les développeurs commettent avec le stockage web ?
Les erreurs les plus importantes ont une racine commune : traiter le stockage côté client comme s'il s'agissait d'une base de données sécurisée côté serveur.
- Stocker des JWT dans localStorage : Les jetons d'authentification stockés dans localStorage sont accessibles à tout script sur la page. Une seule vulnérabilité XSS expose le jeton de chaque utilisateur. Utilisez plutôt des cookies HttpOnly pour les jetons d'authentification.
- Absence de logique d'expiration : localStorage n'a pas de TTL. Les développeurs qui stockent des données sans intégrer de logique d'expiration laissent des données obsolètes et sensibles sur les appareils indéfiniment.
- Supposer que la même origine signifie la sécurité : La politique de même origine bloque les sites externes, pas les scripts malveillants chargés depuis le même site (XSS, bibliothèques tierces compromises).
- Ignorer l'accès aux scripts tiers : Intégrer des scripts d'analyse ou publicitaires sans vérifier ce qu'ils lisent depuis localStorage.
- Absence de porte de consentement pour le stockage de suivi : Écrire des identifiants d'analyse dans localStorage avant d'obtenir le consentement de l'utilisateur, une violation directe du GDPR. [2]
- Stocker des PII redondantes : Mettre en cache des réponses d'API qui incluent des profils utilisateur complets dans localStorage "pour la performance" sans considérer la surface d'exposition.
IndexedDB est-il plus privé que localStorage ?
IndexedDB n'est pas intrinsèquement plus privé que localStorage. Les deux sont régis par la politique de même origine, les deux sont accessibles au JavaScript s'exécutant sur la page, et les deux sont vulnérables aux attaques XSS.
IndexedDB offre une plus grande capacité de stockage et prend en charge les données structurées et les blobs binaires, ce qui le rend adapté aux applications hors ligne complexes. Mais du point de vue de la confidentialité et de la sécurité, les risques sont comparables. Les données stockées dans IndexedDB ne sont pas non plus chiffrées par défaut, et elles persistent indéfiniment à moins d'être explicitement supprimées.
Le choix entre IndexedDB et localStorage doit être dicté par la complexité des données et les exigences de volume, et non par des hypothèses de confidentialité. Aucun des deux n'est approprié pour les données personnelles sensibles sans chiffrement au niveau de l'application et contrôles d'accès stricts.
Conclusion
Le débat SessionStorage vs. LocalStorage : Implications pour la vie privée des API de stockage web n'est pas une simple note de bas de page technique, il a des conséquences directes sur la vie privée des utilisateurs, la conformité réglementaire et la sécurité des applications. La persistance indéfinie de localStorage et son accessibilité inter-onglets en font un mécanisme de stockage à haut risque lorsqu'il est mal utilisé, tandis que la suppression automatique de sessionStorage à la fermeture de l'onglet en fait le choix le plus défendable pour l'état temporaire.
Prochaines étapes concrètes pour les développeurs et les propriétaires de sites web en 2026 :
- Auditez toutes les utilisations de localStorage et sessionStorage dans les scripts propriétaires et tiers à l'aide des outils de développement du navigateur (onglet Application).
- Supprimez immédiatement tous les jetons d'authentification, les PII ou les identifiants sensibles du stockage côté client.
- Remplacez le stockage de jetons d'authentification basé sur localStorage par des cookies HttpOnly, Secure, SameSite gérés côté serveur.
- Mettez en œuvre un flux de gestion du consentement, en utilisant une plateforme telle que Biscotti CMP, pour subordonner les écritures non essentielles de localStorage à un consentement utilisateur documenté.
- Intégrez une logique d'expiration dans toutes les données localStorage qui doivent persister, et appliquez un nettoyage lors de la déconnexion.
- Effectuez un audit des scripts tiers pour comprendre ce que le code externe peut lire depuis le stockage de votre origine.
- Formez les équipes de développement à la prévention des XSS en tant que principal vecteur d'attaque contre les deux types de stockage.
Les API de stockage web sont des outils puissants. Utilisées sans discipline en matière de confidentialité, elles deviennent des vecteurs de responsabilité. Utilisées avec une portée délibérée, une gestion du consentement et une hygiène de sécurité, elles remplissent leur objectif sans compromettre les utilisateurs qui font confiance à votre application.
FAQ
Q: Quelle est la principale différence entre sessionStorage et localStorage ? localStorage persiste les données indéfiniment à travers les sessions et est partagé entre tous les onglets de la même origine. sessionStorage stocke les données uniquement pendant la durée de vie de l'onglet actuel et est supprimé automatiquement lorsque l'onglet se ferme.
Q: localStorage peut-il être utilisé pour suivre les utilisateurs sans cookies ? Oui. Un identifiant unique stocké dans localStorage survit à la suppression des cookies et peut être utilisé pour suivre les utilisateurs sur plusieurs visites du même site, fonctionnant comme un mécanisme de suivi persistant.
Q: sessionStorage est-il sûr pour stocker des mots de passe ? Non. sessionStorage n'est pas chiffré et est accessible à tout JavaScript s'exécutant sur la page, y compris les scripts malveillants injectés. Les mots de passe ne doivent jamais être stockés dans un mécanisme de stockage côté client.
Q: Le GDPR s'applique-t-il à localStorage ? Oui. En vertu du GDPR, le stockage d'identifiants de suivi ou de données personnelles dans localStorage sans base légale, généralement un consentement utilisateur explicite à des fins non essentielles, est une violation de la conformité équivalente à l'utilisation de cookies sans consentement.
Q: Les scripts tiers peuvent-ils lire mes données localStorage ?
Oui, si ces scripts sont chargés et exécutés dans la même origine. Les scripts d'analyse ou publicitaires tiers intégrés via des balises <script> s'exécutent dans le contexte d'origine de la page hôte et peuvent lire toutes les données localStorage pour cette origine.
Q: L'effacement des cookies efface-t-il également localStorage ? Pas toujours. Dans la plupart des navigateurs, l'effacement des "cookies" seul n'efface pas localStorage. Les utilisateurs doivent spécifiquement effacer les "données de site" ou les "cookies et autres données de site" pour supprimer le contenu de localStorage.
Q: Le mode incognito est-il à l'abri du suivi localStorage ? Le mode incognito empêche les données localStorage de persister après la fermeture de la fenêtre privée, mais au sein d'une session incognito active, localStorage est toujours lisible par tous les scripts de la page.
Q: Que dois-je utiliser à la place de localStorage pour les jetons d'authentification ? Utilisez des cookies HttpOnly, Secure, SameSite gérés côté serveur. Ces cookies sont inaccessibles à JavaScript, éliminant le risque de vol de jetons basé sur XSS que localStorage comporte.
Q: IndexedDB est-il plus sécurisé que localStorage ? Non. IndexedDB est soumis aux mêmes vulnérabilités XSS et à la même politique de même origine que localStorage. Il offre une plus grande capacité et un meilleur support de la structure des données, mais aucune garantie supplémentaire de confidentialité ou de sécurité.
Q: Quelle quantité de données localStorage et sessionStorage peuvent-ils contenir ? La plupart des navigateurs modernes allouent environ 5 à 10 Mo de stockage par origine pour chaque type de stockage, ce qui est nettement plus que la limite de 4 Ko typique des cookies. [2]
Références
[1] Sessionstorage - https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage?utm_source=openai
[2] What Is Localstorage Sessionstorage - https://inspectwp.com/en/knowledge-base/what-is-localstorage-sessionstorage?utm_source=openai
[3] Html5 Web Storage Security Risks Safeguarding Localstorage And Sessionstorage - https://www.dopethemes.com/html5-web-storage-security-risks-safeguarding-localstorage-and-sessionstorage/?utm_source=openai
[4] Localstorage - https://javascript.info/localstorage?utm_source=openai
[5] Localstorage Sessionstorage - https://www.w3docs.com/learn-javascript/localstorage-sessionstorage?utm_source=openai
[6] Cookies Vs Localstorage Vs Sessionstorage What Each One Exactly Means - https://www.interserver.net/tips/kb/cookies-vs-localstorage-vs-sessionstorage-what-each-one-exactly-means/?utm_source=openai