Ton navigateur peut embarquer un véritable petit disque dur. Le stockage web est une fonctionnalité sous-cotée qui transforme l'expérience utilisateur : navigation hors-ligne, préférences persistantes, données conséquentes sans rechargement serveur.
Quatre API principales : localStorage, sessionStorage, IndexedDB et la Cache API. Chacune a son cas d'usage. On les compare, et je montre comment stocker des données structurées sans faire ramer ton app. Et la sécurité, parce que stocker chez le client c'est pratique mais risqué.
Exemple concret : localStorage.setItem('theme', 'dark') suffit pour retenir le thème. Mais tout ne se vaut pas. Les cookies sont limités à 4 Ko et envoyés à chaque requête ; on les réserve à l'authentification.
Les API de stockage disponibles dans le navigateur
Tu as cinq APIs côté client, et elles ne se valent pas. localStorage et sessionStorage sont synchrones, limités à 5 Mo, idéals pour des préférences. IndexedDB est asynchrone, stockage structuré, pas de limite concrète. La Cache API gère les réponses réseau, souvent avec les service workers. Les cookies, eux, sont ridicules (4 Ko) et envoyés à chaque requête, cantonnés à l’authentification.
Alors laquelle choisir ? Mon avis : pour une valeur unique comme le thème, localStorage suffit. Pour des données complexes comme un carnet d’adresses, passe à IndexedDB. Ne touche jamais à localStorage pour des opérations synchrones lourdes, tu bloques le thread.
La Cache API est à part : tu l’utilises pour mettre en cache des ressources hors-ligne. Par exemple :
Résumé : localStorage et sessionStorage pour les petites données clé-valeur synchrones. IndexedDB pour les données relationnelles ou volumineuses (mais prépare-toi à écrire plus de code). Cache API pour le offline. Les cookies, limite-les à l’auth. Personnellement, je démarre toujours par IndexedDB dès que j’ai besoin de stocker plus de quelques ko structurés — les wrappers comme idb rendent l’API bien plus agréable.
Quand utiliser localStorage vs sessionStorage ?
La règle : sessionStorage disparaît à la fermeture de l'onglet, localStorage persiste jusqu'à suppression explicite. Pas de différence de capacité (5 Mo chacun), mais d'isolation : localStorage est partagé entre les onglets du même domaine, sessionStorage est isolé par onglet. J'utilise localStorage pour les réglages (thème, langue), et sessionStorage pour les tokens d'authentification ou l'état d'un workflow.
Côté sécurité, les deux sont exposés aux XSS. Mais sessionStorage offre une sécurité supplémentaire par sa nature éphémère. Mon conseil : ne stocke jamais de données sensibles dans localStorage si tu peux l'éviter. Un token API ? Mets-le dans sessionStorage. Comme ça, les dégâts sont limités à la session.
En pratique, je choisis selon la persistance : si l'information doit survivre à la fermeture, c'est localStorage. Sinon, sessionStorage.
Pas de mystère : le choix dépend du besoin de durée de vie. Si tu hésites, commence par sessionStorage, tu passeras à localStorage plus tard.
Stocker de grandes quantités de données structurées
Tu veux stocker des milliers de produits ou des logs côté client ? Oublie localStorage, il plafonne à 5 Mo et bloque le thread. IndexedDB est la seule API conçue pour ça : asynchrone, sans limite de taille, et capable de gérer des données structurées complexes.
Ce code crée une base avec un object store et un index. Tu peux ajouter des centaines de milliers d'enregistrements sans impact sur l'UI. À mon avis, si tu manipules plus de quelques centaines d'objets, passe à IndexedDB.
Pense aux librairies comme Dexie.js pour simplifier l'API verbose. Et n'oublie pas la persistance : appelle navigator.storage.persist() pour éviter la purge automatique. En résumé, IndexedDB est l'outil robuste pour les grosses données structurées.
Bonnes pratiques de sécurité pour le stockage web
Premier réflexe : ne fais jamais confiance au client pour des données sensibles. localStorage et IndexedDB sont vulnérables aux XSS. Un simple script injecté peut exfiltrer tout ton stockage.
Mon conseil : réserve localStorage et sessionStorage à des préférences non critiques. Pour l'authentification, utilise des cookies HttpOnly et Secure. Nettoie le stockage à la déconnexion :
Ajoute une Content Security Policy stricte pour limiter l'impact des XSS. Et surtout, ne stocke jamais de mots de passe en clair, même dans IndexedDB. Le client n'est pas un endroit sûr.
Conclusion
Si tu retiens une chose du stockage web, c'est que localStorage n'est pas une solution universelle. Trop de développeurs l'utilisent par défaut, alors qu'IndexedDB serait plus adapté pour des données structurées ou volumineuses. Commence toujours par évaluer la nature de tes données avant de choisir une API.
Pour une app typique, sessionStorage pour les tokens éphémères et IndexedDB pour les préférences ou le cache local couvrent 90% des besoins. localStorage, je le réserve à des valeurs vraiment triviales.