Cookies, stockage local, cache et empreintes de navigateur

Ces notions apparaissent souvent ensemble dans les paramètres de confidentialité, les instructions de débogage et les produits de gestion de profils. Leurs comportements diffèrent suffisamment pour que « effacer le navigateur » soit une instruction incomplète.

Un modèle mental pratique

Mécanisme	Qui le crée ou le contrôle	Périmètre habituel	Usage courant	Envoyé automatiquement avec une requête ?
Cookie HTTP	Un serveur le définit ; le navigateur le stocke et le renvoie selon les règles de périmètre	Hôte ou domaine, chemin, durée de vie et conditions de connexion	Identifiants de session, préférences, état de lutte contre les abus	Oui, lorsque la requête correspond à son périmètre
localStorage	JavaScript du site	Origine, sous réserve du partitionnement du navigateur et des politiques	État applicatif persistant sous forme de paires clé-valeur	Non
sessionStorage	JavaScript du site	Origine au sein d’une session de navigation de premier niveau	État temporaire d’un onglet ou d’un flux	Non
Cache HTTP	Navigateur et règles de mise en cache HTTP	Clé de cache, directives de réponse, politique du navigateur	Réutilisation des réponses pour réduire la latence et le trafic	Il peut satisfaire ou revalider une requête
API Cache Storage	JavaScript du site ou du service worker	Origine ou partition de stockage	Ressources hors ligne et réponses gérées par l’application	Pas de pièce jointe automatique ; le script en contrôle l’usage
Empreinte de navigateur	Un site ou un autre observateur mesure des signaux	Dépend de l’observateur et des signaux	Sécurité, détection de fraude, analyse ou suivi	Certains signaux sont visibles dans les requêtes ; d’autres exigent du code actif

Les cinq premières lignes concernent un état conservé. La dernière décrit une méthode d’observation et de corrélation, même si un état conservé peut aussi constituer l’une de ses données d’entrée.

Cookies : un état destiné au serveur avec des règles de périmètre

HTTP est en grande partie sans état. Les cookies permettent à un serveur de donner au navigateur une paire nom-valeur et de la recevoir lors de requêtes ultérieures correspondantes. La RFC 6265 définit l’en-tête de réponse Set-Cookie, l’en-tête de requête Cookie et le modèle de stockage du navigateur.

Un cookie peut être :

• limité à la session, conservé jusqu’à la fin de la session telle que définie par le navigateur ;
• persistant, avec une date d’expiration ou une durée maximale ;
• limité à l’hôte, renvoyé uniquement à l’hôte qui l’a défini ;
• limité au domaine, admissible pour le domaine indiqué et les sous-domaines correspondants ;
• limité au chemin, renvoyé uniquement pour les chemins de requête correspondants ;
• Secure, renvoyé uniquement sur un canal sécurisé selon la définition du navigateur ; et
• HttpOnly, inaccessible aux API de cookies destinées aux scripts, mais toujours disponible pour les requêtes HTTP.

Ces attributs influencent la transmission et l’accès par script. Ils ne transforment pas la valeur du cookie en limite de sécurité indépendante. La RFC 6265 avertit expressément qu’il ne faut pas se fier à l’attribut Path pour la sécurité et recommande un transport sécurisé ainsi qu’une protection supplémentaire du contenu sensible des cookies.

Pourquoi la suppression des cookies vous déconnecte

De nombreux services stockent un identifiant de session aléatoire dans un cookie, tout en conservant le compte et les détails de la session sur le serveur. Supprimer ce cookie retire au navigateur sa copie de l’identifiant : la requête suivante ne présente donc plus la même session. Le compte côté serveur et d’autres sessions peuvent subsister.

Cela explique aussi pourquoi la copie de cookies d’authentification est sensible. Un identifiant de session utilisable peut agir comme un identifiant d’accès. Ne collez jamais de cookies bruts dans un ticket, un journal, une sortie d’automatisation ou une messagerie d’équipe.

Stockage local : un état contrôlé par script pour une origine

Le standard HTML définit localStorage comme l’accès à la zone de stockage local d’une origine. Il est conçu pour couvrir plusieurs fenêtres et persister au-delà de la session en cours. Le stockage contient des paires clé-valeur de chaînes et reste accessible aux scripts autorisés à agir pour cette origine.

Une origine associe normalement le schéma, l’hôte et le port. Les adresses suivantes relèvent donc de périmètres de stockage différents :

• https://app.example.test
• http://app.example.test
• https://admin.example.test
• https://app.example.test:8443

Le chemin de l’URL ne fait pas partie de l’origine. Les pages /billing/ et /support/ d’une même origine peuvent accéder à la même zone de stockage local, sauf si l’application applique sa propre séparation logique.

Contrairement à un cookie, une entrée localStorage n’est pas automatiquement jointe aux requêtes HTTP. Le script du site doit la lire et décider de son usage. Elle convient donc aux préférences d’interface, aux brouillons et aux données d’application, mais tout script exécuté avec l’autorité de l’origine peut potentiellement y accéder. Une conception de session sensible doit tenir compte de la compromission des scripts au lieu de supposer que « local » signifie secret.

Ici, la persistance signifie que les données peuvent survivre à une session de navigation. Elle ne signifie pas une conservation permanente. Une personne peut les effacer, une politique du navigateur peut les restreindre et le navigateur peut appliquer des règles de stockage ou d’éviction.

sessionStorage a une durée de vie différente

sessionStorage est associé à l’origine et à une session de navigation de premier niveau. Il convient à un état qui doit subsister pendant le déroulement d’un flux dans un onglet ou une fenêtre, puis prendre fin avec cette session. Le cycle de vie d’un onglet dupliqué ou restauré peut varier selon le navigateur ; les applications ne doivent donc pas en faire l’unique enregistrement d’un travail critique.

Le stockage local n’est qu’un mécanisme de données de site

Les applications web modernes peuvent également conserver des données dans IndexedDB, Cache Storage, les inscriptions de service workers, l’Origin Private File System, les autorisations et d’autres espaces gérés par le navigateur. Effacer uniquement localStorage dans les outils de développement peut donc laisser d’autres états intacts.

Les recommandations de confidentialité du standard HTML préconisent que les navigateurs permettent d’effacer ensemble les mécanismes de stockage persistant. Autrement, un site pourrait utiliser un espace de stockage pour recréer un identifiant supprimé d’un autre.

Cache : un mot pour plusieurs mécanismes

Le cache HTTP

La RFC 9111 définit un cache HTTP comme un espace de messages de réponse accompagné du système qui contrôle leur stockage, leur récupération et leur suppression. Un cache de navigateur peut réutiliser une réponse encore fraîche ou revalider une réponse périmée, ce qui réduit la latence et les transferts réseau.

La clé de cache comprend au moins la méthode de requête et l’URI cible. Les en-têtes de réponse déterminent si une réponse peut être réutilisée et pendant combien de temps. Le cache HTTP est une couche d’optimisation. La présence d’une image ou d’un script en cache ne signifie normalement pas que la personne est connectée.

L’état du cache peut néanmoins affecter la confidentialité. Dans certains modèles de menace, le temps de réponse ou la présence préalable d’une ressource peut révéler des informations. Les recommandations du W3C sur les empreintes incluent l’observation des ressources mises en cache parmi les moyens d’inférer la configuration du navigateur ou de l’utilisateur.

Cache Storage et service workers

L’API Cache Storage fournit à un site des objets Cache explicites contrôlés par script, souvent pour des applications web hors ligne. La spécification Service Workers indique que ces caches sont distincts du cache HTTP du navigateur, isolés par origine et mis à jour ou supprimés par la logique de l’application plutôt que par les règles ordinaires de fraîcheur HTTP.

Cette différence compte pendant le débogage :

• effacer les « images et fichiers en cache » cible le cache ordinaire du navigateur ;
• effacer les données du site peut aussi supprimer Cache Storage et l’état des service workers ; et
• recharger en contournant le cache HTTP peut laisser un service worker actif contrôler les requêtes.

Nommez le cache concerné avant de choisir comment l’inspecter ou l’effacer.

Le partitionnement du stockage ajoute une clé

Le périmètre par origine permettait autrefois à un tiers intégré de lire le même stockage lorsqu’il apparaissait dans de nombreux sites de premier niveau. Les navigateurs modernes ajoutent de plus en plus le site de premier niveau ou un contexte associé à la clé de stockage.

Chrome indique que son partitionnement du stockage empêche un cadre example.com intégré à a.com de partager automatiquement Local Storage, IndexedDB, Cache Storage, les service workers et certains mécanismes de communication avec le même cadre intégré à b.com. Selon Chrome, cette fonction est activée pour tous les utilisateurs depuis Chrome 115, avec des changements ultérieurs pour certaines API supplémentaires.

Le partitionnement explique un résultat autrement surprenant : une même origine intégrée peut voir un stockage différent selon le site qui l’entoure. Cela ne signifie pas que tout stockage utilise partout un modèle universel à deux clés. Les versions du navigateur, les contextes de premier niveau ou intégrés, les autorisations d’accès au stockage, les politiques d’entreprise, les extensions et les règles propres aux API peuvent modifier le résultat.

Testez le contexte exact au lieu de tirer une conclusion du seul nom de domaine.

Empreintes de navigateur : des signaux observés, pas un dossier

Le W3C définit l’empreinte de navigateur comme la capacité d’identifier ou de réidentifier un utilisateur, un agent utilisateur ou un appareil à partir de paramètres de configuration ou d’autres caractéristiques observables. Ses recommandations de 2025 distinguent plusieurs formes :

• L’empreinte passive utilise des informations déjà observables dans les requêtes ou sur le réseau, comme les en-têtes et l’adresse IP.
• L’empreinte active exécute du code pour observer des caractéristiques telles que la taille de la fenêtre, les polices, les appareils connectés, les performances, les capteurs ou le rendu graphique.
• La corrélation d’événements transitoires relie des contextes au moyen de changements quasi simultanés de l’appareil ou de l’environnement.
• Les techniques semblables aux cookies stockent et récupèrent un état par des mécanismes susceptibles de survivre aux cookies ordinaires ou de les recréer.

Une empreinte est rarement une valeur immuable stockée par le navigateur. Un observateur choisit des signaux, les combine et évalue la force de leur correspondance avec une visite antérieure. Le résultat peut changer après une mise à jour du navigateur, un redimensionnement de la fenêtre, l’ajout de polices, la connexion d’un appareil ou un changement de route réseau. Il peut aussi rester similaire après l’effacement des cookies, car nombre de signaux sous-jacents sont inchangés.

Une empreinte ne prouve pas l’identité

Un ensemble de signaux peut être commun à de nombreuses personnes ou évoluer pour une même personne. Les sites peuvent aussi associer une empreinte à une connexion, à l’historique d’un compte côté serveur, à la réputation d’un réseau ou à des identifiants stockés. Une reconnaissance après l’effacement de données ne prouve donc pas que l’empreinte en était la seule cause.

Pour la même raison, modifier un seul paramètre visible ne garantit pas une nouvelle identité. Une configuration cohérente et courante peut réduire certaines singularités, tandis que de nombreux changements inhabituels et indépendants peuvent produire une combinaison plus rare. Ces signaux ne permettent pas de garantir l’invisibilité ou l’acceptation par un tiers.

Effets réels des actions courantes d’effacement

Action	Effet probable	Ce qui subsiste notamment
Supprimer les cookies d’un site	Supprime les cookies correspondants détenus par le navigateur et déconnecte souvent ce profil	Les données du compte côté serveur, les autres appareils et les espaces autres que les cookies peuvent subsister
Supprimer les cookies et autres données du site	Peut supprimer les cookies, Web Storage, IndexedDB, les service workers et les états associés, selon l’interface et le périmètre du navigateur	Le gestionnaire de mots de passe, les téléchargements, les données du compte et les signaux observables de l’appareil sont distincts
Supprimer les images et fichiers en cache	Supprime le contenu ordinaire des réponses en cache	Les cookies, le stockage local et Cache Storage peuvent exiger une sélection distincte
Effacer l’historique	Supprime les URL visitées enregistrées et les suggestions associées dans le périmètre choisi	Les fichiers téléchargés et les enregistrements détenus par les sites subsistent
Supprimer un profil de navigateur	Supprime de l’appareil ses favoris, son historique, ses mots de passe et d’autres paramètres locaux	Les données de compte synchronisées, les fichiers téléchargés ou exportés, les sauvegardes et les données côté serveur peuvent subsister
Créer un profil	Commence avec un autre ensemble d’états de profil	L’appareil, le système d’exploitation, la version du navigateur et le réseau peuvent encore apparaître comme liés

Le guide de Chrome sur les données de navigation distingue l’historique, les cookies et autres données de site, les images et fichiers en cache, l’historique des téléchargements, la saisie automatique, les paramètres des sites et les données d’applications hébergées. Il précise aussi que la suppression de l’historique des téléchargements laisse les fichiers téléchargés sur l’ordinateur et que la suppression de données lorsque la personne est connectée peut affecter le compte Google et d’autres appareils synchronisés.

L’effet exact dépend de la période choisie, du profil, de l’état du compte, de la version du navigateur et des politiques d’entreprise. Lisez le texte de confirmation avant de supprimer des données potentiellement difficiles à récupérer.

Effet des profils de navigateur distincts sur chaque mécanisme

Un profil persistant correctement séparé doit posséder son propre ensemble de cookies, ses zones Web Storage, ses bases de données de site, son Cache Storage, son cache HTTP, son historique, ses autorisations de sites et l’état de ses extensions. Cela empêche le profil B d’hériter simplement de la session stockée du profil A.

Plusieurs signaux peuvent rester communs :

• moteur et version du navigateur ;
• système d’exploitation et matériel ;
• polices installées sur le système et caractéristiques de l’écran ;
• paramètres de langue, de fuseau horaire ou d’accessibilité hérités de l’hôte ;
• adresse IP et chemin réseau lorsqu’aucune route distincte n’est configurée ; et
• comportement de l’opérateur ou connexions qui relient l’activité au niveau applicatif.

Des profils différents peuvent aussi exposer des signaux différents par leurs extensions, autorisations, dimensions de fenêtre, paramètres linguistiques ou routes de proxy. L’effet net dépend de l’implémentation et du contexte. La séparation des profils doit être évaluée comme une isolation de l’état, non comme une garantie d’empreinte différente.

Diagnostiquer le symptôme avant de tout effacer

« J’ai été déconnecté »

Examinez d’abord les cookies. Un cookie de session peut avoir expiré, avoir été supprimé, avoir été rejeté par une politique du navigateur ou avoir été invalidé par le serveur. Le stockage local peut contribuer à l’interface, mais il ne constitue normalement pas le cookie envoyé automatiquement pour authentifier une requête HTTP.

« Le site a oublié mon brouillon ou mes données hors ligne »

Examinez le stockage local, IndexedDB, Cache Storage et l’état des service workers. Confirmez l’origine et vérifiez si la page se trouve au premier niveau ou est intégrée dans un autre site, car le partitionnement peut modifier le stockage disponible.

« Le premier rechargement est lent »

Un cache HTTP vide ou périmé est une cause probable. Le réseau, le serveur et le service worker peuvent produire le même symptôme : consignez donc le temps des requêtes et l’état du cache avant de conclure.

« Le site reconnaît encore l’environnement après l’effacement des données »

Plusieurs explications restent possibles : le compte est encore connecté ailleurs, le serveur a relié la visite au moyen du compte ou de données réseau, un autre espace du navigateur a subsisté, ou des caractéristiques observables ont corrélé les sessions. Traitez l’empreinte comme une hypothèse, pas comme la réponse automatique.

Conclusion orientée vers la décision

Choisissez la mesure selon le mécanisme :

• examinez ou effacez les cookies lorsque la question concerne les sessions côté serveur ;
• examinez les espaces de site délimités par origine lorsqu’une application web conserve un état local ;
• distinguez le cache HTTP de Cache Storage pour diagnostiquer un contenu périmé ou hors ligne ;
• utilisez un profil persistant distinct lorsque l’état de travail stocké doit rester indépendant ; et
• traitez l’empreinte comme une corrélation entre signaux observables, avec des limites que l’effacement de données ou la modification d’un seul réglage ne peut éliminer.

Ce modèle évite deux erreurs coûteuses : supprimer plus d’état que nécessaire et supposer qu’un ensemble de cookies vide crée une nouvelle identité d’appareil.

Limites

Le comportement du stockage web et de la confidentialité évolue selon les navigateurs et les versions. Les règles relatives aux cookies tiers, le partitionnement du stockage, l’éviction, la synchronisation, les politiques d’entreprise, les extensions et les modes de navigation privée peuvent modifier les comportements décrits. Ce guide explique les standards et la documentation actuelle de Chrome à la date de consultation ; il ne décrit pas toutes les implémentations de navigateurs ou de sites web.