Cookies vs localStorage : Quoi Stocker, Où et Pourquoi ?

Dans le développement web frontend, vous avez deux moyens principaux pour stocker des données directement dans le navigateur de l’utilisateur : les cookies et le localStorage (ainsi que son cousin sessionStorage). Le choix entre eux n’est pas anodin : il impacte la sécurité, les performances et même le SEO. Utiliser le mauvais outil peut ouvrir des failles de sécurité critiques ou dégrader l’expérience utilisateur. Décryptons leurs rôles respectifs pour savoir quoi stocker, où, et surtout pourquoi.

Le Cookie : Le Vieux Soldat du Web (HTTP-Aware)

Le cookie est un mécanisme ancien, standardisé et polyvalent. Techniquement, c’est un petit morceau de données qu’un serveur peut envoyer au navigateur via un en-tête HTTP Set-Cookie. Le navigateur le renverra automatiquement au serveur dans l’en-tête Cookie de chaque requête ultérieure vers le même domaine.

• Comment ça marche ? Le serveur dit : « Tiens navigateur, stocke cette info (session_id=abc123) et renvoie-la-moi à chaque fois que tu me parles. » Le navigateur obéit.

• Ses Caractéristiques Clés :

  • Lié au domaine et (optionnellement) au chemin.

  • Peut avoir une durée de vie (Expires ou Max-Age) ou être de session (supprimé à la fermeture du navigateur).

  • Envoyé automatiquement avec les requêtes HTTP, y compris les requêtes pour des images, CSS, API… Ce qui peut alourdir inutilement la bande passante si le cookie est gros.

  • Accessible côté client (JavaScript) ET côté serveur.

  • Possède des attributs de sécurité cruciaux :

    • HttpOnly : Empêche l’accès au cookie via JavaScript (document.cookie). C’est une défense majeure contre les attaques XSS pour vol de session.

    • Secure : N’est envoyé que sur des connexions HTTPS.

    • SameSite : Contrôle si le cookie est envoyé avec les requêtes cross-site (défense contre les attaques CSRF). La valeur Lax ou Strict est aujourd’hui recommandée.

Le localStorage : Le Tiroir de Stockage Local (JavaScript-Only)

Introduit avec HTML5, localStorage (et sessionStorage) fait partie de l’API Web Storage. C’est un simple stockage clé-valeur accessible uniquement via JavaScript, dans le contexte de l’origine (protocole + domaine + port).

• Comment ça marche ? C’est un objet JavaScript (window.localStorage) qui persiste au-delà des fermetures de session/navigateur (contrairement à sessionStorage). Les données ne sont jamais envoyées automatiquement au serveur.

• Ses Caractéristiques Clés :

  • Capacité bien plus grande (~5-10 Mo contre 4 Ko par cookie).

  • Accessible uniquement par JavaScript dans le même contexte d’origine.

  • Les données ne sont PAS envoyées automatiquement au serveur. Vous devez explicitement les lire et les inclure dans vos requêtes (ex: dans un en-tête ou le corps d’une requête).

  • Pas d’expiration automatique (persiste jusqu’à ce que le code JS ou l’utilisateur le supprime).

  • Stocke uniquement des strings. Pour les objets, il faut utiliser JSON.stringify() et JSON.parse(). Pour plus de détails, suivez ce lien.

Le Guide de Choix Définitif : Quoi Stocker Où ?

Le choix se résume à une question : Ces données doivent-elles être automatiquement envoyées au serveur à chaque requête ?

🍪 Utilisez les COOKIES pour… (Les Données de « Fonctionnement » Serveur)

Les cookies sont parfaits pour les données dont le serveur a besoin à chaque fois pour traiter la requête. Leur force est leur automaticité.

• L’Identifiant de Session (Token) : C’est L’USAGE PRINCIPAL et CORRECT. Un token de session ou un JWT court, stocké dans un cookie HttpOnly, Secure et SameSite=Lax. Le navigateur l’envoie automatiquement, et il est inaccessible aux scripts malveillants via XSS grâce à HttpOnly. C’est la manière la plus sûre de gérer l’authentification pour une application web.

• Les Préférences Serveur-Side : Un choix de langue, un identifiant de thème dont le serveur a besoin pour render la page initiale.

• Le Consentement RGPD : Un simple flag gdpr_consent=true peut être stocké en cookie pour ne pas redemander à l’utilisateur à chaque visite.

Règle d’or pour les cookies : Toujours utiliser Secure (HTTPS uniquement), toujours utiliser HttpOnly sauf besoin explicite côté JS, et toujours définir SameSite (au moins Lax).

💾 Utilisez le LOCALSTORAGE pour… (Les Données Purement Client-Side)

Le localStorage est idéal pour les données qui n’ont rien à faire sur le serveur et qui sont uniquement utiles pour l’expérience utilisateur côté client.

• Le Thème de l’Application (dark/light mode) : Une préférence purement visuelle gérée par le CSS/JS du frontend.

• Les Brouillons de Formulaire : Sauvegarder automatiquement ce que l’utilisateur tape dans un long formulaire, pour éviter une perte de données en cas de rafraîchissement accidentel.

• Les Données de Configuration d’une Application Rich Client (SPA) : Des paramètres d’UI complexes dans une application comme Figma ou un outil de design.

• Le Cache de Données Non-Sensibles : Stocker le résultat d’une lourde requête API pour une durée limitée, pour éviter de ressolliciter le serveur inutilement (avec un timestamp d’expiration).

⚠️ Avertissement CRITIQUE pour localStorage : NE JAMAIS y stocker des données sensibles. Pas de token d’authentification, pas de données personnelles identifiantes (email, nom), pas de secrets. Ces données sont vulnérables au vol par des scripts XSS.

Le Tableau Comparatif (Pour Choisir Rapidement)

Séparation des Préoccupations

Pour résumer de manière simple et mnémotechnique :

• « Le serveur a besoin de le savoir ? » → Cookie (en sécurisant avec HttpOnly/Secure/SameSite).

• « Seul le frontend en a besoin ? » → localStorage (en n’y mettant rien de sensible).

Le pire anti-pattern absolu est de stocker un token JWT d’authentification dans le localStorage. C’est le moyen le plus simple d’exposer vos utilisateurs au vol de session par une simple faille XSS.

En respectant cette séparation claire – les cookies pour la communication automatique client-serveur sécurisée, le localStorage pour la persistance purement côté client – vous bâtissez des applications plus robustes, plus performantes et plus sûres. Votre futur vous (et vos utilisateurs) vous remercieront.