Cookies vs localStorage vs sessionStorage : Choisir le stockage client

Lors de la création d'une application web, vous devez souvent stocker des données côté client—qu'il s'agisse de la préférence de thème d'un utilisateur, d'un panier d'achat ou d'un jeton d'authentification. Les trois principales options sont les cookies, localStorage et sessionStorage. Chacune a des caractéristiques distinctes qui la rendent adaptée à différents scénarios. Choisir la mauvaise peut entraîner des vulnérabilités de sécurité, des problèmes de performance ou une mauvaise expérience utilisateur.

Cet article détaille les différences, fournit des conseils pratiques et vous aide à décider quel mécanisme de stockage utiliser pour votre prochain projet.

Comparaison rapide

Avant d'entrer dans les détails, voici un aperçu global des trois types de stockage :

Cookies : le stockage client original

Les cookies existent depuis les débuts du web. Ce sont de petits morceaux de données (max ~4 Ko) que le navigateur stocke et envoie automatiquement au serveur à chaque requête HTTP vers le même domaine.

Quand utiliser les cookies

• Sessions d'authentification : Stockez des identifiants de session ou des jetons que le serveur doit valider à chaque requête. Utilisez les attributs HttpOnly, Secure et SameSite pour atténuer les risques de XSS et CSRF.
• Personnalisation côté serveur : Lorsque le serveur doit connaître les préférences de l'utilisateur (par exemple, langue, thème) avant de rendre la page.
• Suivi et analyse : Les cookies peuvent persister entre les sessions et être partagés entre sous-domaines s'ils sont configurés ainsi.

Considérations de sécurité

Les cookies sont envoyés automatiquement, ce qui les rend vulnérables au CSRF s'ils sont utilisés pour l'authentification sans protections supplémentaires. Définissez toujours l'attribut SameSite (Lax ou Strict) et envisagez d'utiliser des jetons CSRF. Pour les données sensibles, utilisez HttpOnly pour empêcher l'accès JavaScript, réduisant ainsi l'impact du XSS.

Exemple de définition d'un cookie sécurisé dans une réponse HTTP :

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

localStorage : stockage clé-valeur persistant

localStorage offre un simple stockage clé-valeur qui persiste même après la fermeture du navigateur. Les données sont stockées par origine (protocole + domaine + port) et ne sont pas envoyées automatiquement au serveur. Il est idéal pour stocker des données non sensibles qui doivent survivre aux rechargements de page et aux redémarrages du navigateur.

Quand utiliser localStorage

• Préférences utilisateur : Thème (sombre/clair), taille de police, langue ou paramètres de mise en page.
• Mise en cache : Stockez des réponses API ou des données statiques pour réduire les requêtes réseau et améliorer l'expérience hors ligne.
• État côté client : Contenu du panier d'achat, données de formulaire en brouillon ou indicateurs de fonctionnalités.

Considérations de sécurité

localStorage est accessible via JavaScript, donc toute vulnérabilité XSS peut exposer toutes les données stockées. Ne stockez jamais d'informations sensibles comme des mots de passe, des numéros d'identification personnels ou des jetons d'authentification, à moins de disposer de protections XSS robustes. Si vous devez stocker des jetons, envisagez plutôt d'utiliser l'approche des cookies HttpOnly.

Exemple d'utilisation de localStorage :

// Enregistrer la préférence utilisateur
localStorage.setItem('theme', 'dark');

// Récupérer la préférence
const theme = localStorage.getItem('theme');

// Supprimer l'élément
localStorage.removeItem('theme');

sessionStorage : stockage par onglet

sessionStorage est similaire à localStorage mais avec une durée de vie plus courte : les données sont effacées à la fermeture de l'onglet ou de la fenêtre. Il est limité à un seul onglet, donc les données ne sont pas partagées entre les onglets ou fenêtres, même pour la même origine.

Quand utiliser sessionStorage

• Formulaires multi-étapes : Stockez temporairement les données du formulaire au fur et à mesure que l'utilisateur progresse, sans persister après la fin.
• État d'un seul onglet : Données qui ne doivent pas fuiter entre les onglets, comme un état d'authentification temporaire ou un jeton à usage unique.
• Opérations sensibles : Lorsque vous souhaitez que les données soient automatiquement effacées à la fermeture de l'onglet, réduisant l'exposition.

Considérations de sécurité

Comme localStorage, sessionStorage est vulnérable au XSS. Cependant, sa durée de vie limitée et sa portée par onglet réduisent la fenêtre d'opportunité pour les attaquants. Néanmoins, évitez de stocker des données hautement sensibles.

Exemple d'utilisation de sessionStorage :

// Enregistrer les données du formulaire
sessionStorage.setItem('formStep1', JSON.stringify({name: 'John'}));

// Récupérer les données du formulaire
const step1 = JSON.parse(sessionStorage.getItem('formStep1'));

Comment choisir : guide de décision

Utilisez la liste ordonnée suivante pour guider votre décision :

1. Le serveur doit-il lire les données à chaque requête ? Si oui, utilisez des cookies. Exemple : identifiants de session.
2. Les données doivent-elles persister entre les sessions du navigateur ? Si oui, utilisez localStorage. Exemple : préférences utilisateur.
3. Les données doivent-elles être limitées à un seul onglet ? Si oui, utilisez sessionStorage. Exemple : données de formulaire multi-étapes.
4. Les données sont-elles sensibles ? Évitez de les stocker dans localStorage ou sessionStorage. Utilisez des cookies HttpOnly pour les jetons, et ne stockez jamais de mots de passe.
5. Les données sont-elles volumineuses ? Les cookies sont limités à ~4 Ko ; localStorage et sessionStorage offrent une capacité bien plus grande.

Meilleures pratiques de sécurité

• Validez et nettoyez toujours les entrées pour prévenir les XSS, qui peuvent compromettre tout stockage côté client.
• Utilisez des cookies HttpOnly, Secure et SameSite pour les jetons d'authentification afin d'atténuer les XSS et CSRF.
• Évitez de stocker des données sensibles dans localStorage ou sessionStorage. Si vous devez le faire, chiffrez-les et utilisez une expiration courte.
• Mettez en œuvre une Content Security Policy (CSP) pour réduire les risques de XSS.
• Effacez régulièrement les données obsolètes pour éviter d'atteindre les limites de stockage et réduire l'exposition.

FAQ

Puis-je utiliser localStorage pour les jetons d'authentification ?

Ce n'est pas recommandé car localStorage est accessible via JavaScript, ce qui rend les jetons vulnérables aux XSS. Préférez les cookies HttpOnly avec les attributs Secure et SameSite.

Que devient sessionStorage lorsque je duplique un onglet ?

Lorsque vous dupliquez un onglet, le nouvel onglet reçoit une copie du sessionStorage de l'onglet d'origine au moment de la duplication. Ensuite, ils sont indépendants.

Les cookies sont-ils envoyés au serveur à chaque requête ?

Oui, les cookies du domaine actuel sont automatiquement inclus dans chaque requête HTTP, ce qui peut impacter les performances si vous stockez trop de données. Utilisez-les avec parcimonie.

Besoin de formater ou valider rapidement les données JSON que vous stockez ? Essayez notre JSON Formatter pour embellir et déboguer vos charges utiles JSON avant de les enregistrer dans le stockage client.