Stockage dans le navigateur : cookies, Web Storage et IndexedDB comparés

Ce que c'est

Les cookies sont des paires nom-valeur définies par le serveur (Set-Cookie) ou par script et renvoyées avec chaque requête correspondante. La RFC 6265 demande aux agents utilisateurs de prendre en charge au moins 4096 octets par cookie, 50 cookies par domaine et 3000 au total, et les autorise à évincer des cookies au-delà de telles limites. Web Storage (le standard HTML) offre localStorage, qui persiste par origine, et sessionStorage, qui est délimité à un traversable de premier niveau (un onglet ou une fenêtre) et se termine avec lui ; les deux sont synchrones et ne stockent que des chaînes. La page de quota de MDN indique que Web Storage est limité à 10 Mio au total, 5 Mio de stockage local et 5 Mio de stockage de session par origine, et que dépasser cette limite déclenche QuotaExceededError. IndexedDB est asynchrone et transactionnel, stocke des valeurs structurées et des blobs avec des index, et puise dans le quota général de l'origine, qui peut atteindre 60 % du disque dans les navigateurs basés sur Chromium. Le stockage est de type best-effort par défaut et peut être évincé sous pression ; navigator.storage.persist() demande la persistance, navigator.storage.estimate() rapporte l'usage et le quota, et la navigation privée écarte généralement les données à la fin de la session.

Pourquoi c'est important

Un mauvais choix crée des problèmes de sécurité ou de fiabilité : un jeton de session dans localStorage est lisible par n'importe quel script injecté, un état volumineux dans les cookies gonfle chaque requête, une grosse écriture synchrone dans localStorage bloque le thread principal, et une application qui suppose que des données best-effort seront toujours présentes échoue silencieusement après une éviction.

Comment l'appliquer

• Données dont le serveur a besoin à chaque requête (identifiant de session) : un petit cookie avec HttpOnly, Secure et une portée de chemin ; rien d'autre ne va dans les cookies.
• Petites préférences propres au client : localStorage, chaque accès enveloppé dans un try/catch car il peut lever une exception quand il est plein ou bloqué.
• État transitoire par onglet (avancement d'un assistant, filtres de brouillon) : sessionStorage.
• Enregistrements, fichiers, caches hors ligne : IndexedDB, derrière une petite enveloppe afin que le reste du code voie des promesses.
• Versionner la forme stockée (settings:v2) et migrer ou abandonner en cas d'écart.
• Avant de s'appuyer sur le stockage pour des données critiques, appeler persist() et traiter un refus comme « peut disparaître ».

Pièges

Le stockage est par origine : app.example.com et example.com ne partagent pas localStorage, alors qu'un cookie avec Domain=example.com est envoyé aux deux, et les cookies ne s'isolent pas par port. Les navigateurs peuvent en outre partitionner davantage le stockage pour un site intégré dans des cadres tiers. JSON.stringify supprime undefined et transforme Date en chaînes ; désérialiser délibérément.