LocalStorage, SessionStorage ou Cookies : que choisir ?

Un endpoint de login vous renvoie un JWT, et vous avez trois endroits où le stocker : un cookie, localStorage, ou sessionStorage. Faites le mauvais choix et soit une faille XSS embarque le token avec elle, soit le token n’arrive jamais jusqu’à votre API. Les trois stockent des chaînes de caractères dans le navigateur. Ce qui change, c’est qui peut les lire, combien de temps elles survivent, et si le serveur les voit un jour.

Quelle est la différence entre localStorage, sessionStorage et les cookies ?

localStorage et sessionStorage sont la même API, l’interface Storage : setItem, getItem, removeItem, clear, des clés et des valeurs en chaînes de caractères. Ce qui diffère, c’est la durée de vie. localStorage survit à la fermeture du navigateur et au redémarrage de la machine, et reste là jusqu’à ce que quelque chose le vide. Safari fait exception : avec la protection contre le tracking activée, il supprime le stockage écrit par script pour un site avec lequel l’utilisateur n’a pas interagi depuis sept jours. sessionStorage appartient à un seul onglet et meurt quand cet onglet se ferme. Tapez la même URL dans un second onglet et vous obtenez un sessionStorage neuf et vide ; seul « Dupliquer l’onglet » le recopie.

Les cookies sont plus anciens et fonctionnent différemment. Le serveur en pose un avec un header de réponse Set-Cookie, et à partir de là le navigateur l’attache automatiquement à chaque requête correspondante, dans le header Cookie. Cela inclut les requêtes d’images et de feuilles de style, et les appels fetch same-origin que vous n’avez jamais configurés pour envoyer quoi que ce soit. localStorage et sessionStorage ne quittent jamais le navigateur, sauf si votre JavaScript les lit et les envoie quelque part.

Envoyé automatiquement contre jamais envoyé : cette seule propriété tranche la plupart des questions de « lequel choisir ».

Limites de stockage et persistance : le comparatif

Cet écart de capacité explique pourquoi les paniers d’achat et les gros objets de préférences ne vont pas dans les cookies. 4 Ko, ça part vite une fois que vous stockez du JSON, et chaque octet est réexpédié à chaque requête, que l’endpoint en ait besoin ou non. Une page qui charge 40 assets statiques depuis le même domaine, avec un cookie de 3 Ko attaché, envoie ce cookie 40 fois.

Comment lire et écrire chacun en JavaScript

localStorage et sessionStorage s’utilisent avec les mêmes appels :

1
2
3
4
5
6
7
8

// localStorage : survit à la fermeture du navigateur
localStorage.setItem("theme", "dark");
localStorage.getItem("theme");    // "dark"
localStorage.removeItem("theme");

// sessionStorage : disparaît à la fermeture de cet onglet
sessionStorage.setItem("checkout_step", "2");
sessionStorage.getItem("checkout_step"); // "2"

Les deux ne stockent que des chaînes de caractères. setItem("user", {name: "Dan"}) stocke littéralement la chaîne "[object Object]". Sérialisez d’abord :

1
2

localStorage.setItem("user", JSON.stringify({ name: "Dan", plan: "pro" }));
const user = JSON.parse(localStorage.getItem("user"));

Depuis JavaScript, un cookie passe par document.cookie :

1

document.cookie = "theme=dark; path=/; max-age=604800";

On dirait une affectation qui écrase tout. Ce n’en est pas une. Chaque affectation pose ou met à jour un seul cookie, et relire document.cookie vous donne tous les cookies de la page sous la forme d’une seule chaîne jointe par ; . Vous découpez vous-même sur ; puis sur le premier =, ou vous utilisez une petite bibliothèque qui le fait pour vous.

La plupart des cookies sont plutôt posés par le serveur, dans les headers de réponse. C’est aussi la seule façon d’obtenir les protections qui comptent pour tout ce qui est sensible :

1
2
3
4
5
6
7

// Express
res.cookie("session_id", sessionToken, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  maxAge: 1000 * 60 * 60 * 24 * 7, // 7 jours, en ms
});

Cet appel produit un header de réponse du type :

1

Set-Cookie: session_id=a1b2c3...; Max-Age=604800; Path=/; HttpOnly; Secure; SameSite=Lax

HttpOnly, Secure et SameSite : ce qui rend un cookie sûr

• HttpOnly retire complètement le cookie de document.cookie. Le JavaScript de la page ne peut pas le lire, et ça inclut le script injecté par un attaquant. Pour un token de session, c’est la raison principale de préférer un cookie à localStorage : une faille XSS qui exécute du JS arbitraire ne peut toujours pas exfiltrer un cookie HttpOnly.
• Secure empêche le navigateur d’envoyer le cookie en HTTP non chiffré ; il ne part qu’en HTTPS. Activez-le partout en production. Voir Qu’est-ce que TLS et Comment Fonctionne le Chiffrement HTTPS pour savoir ce que vaut cette protection.
• SameSite contrôle si le cookie part sur des requêtes cross-site. Strict ne l’envoie que sur les requêtes same-site. Lax l’envoie encore sur une navigation GET de premier niveau, donc suivre un lien depuis un email vous connecte toujours, mais le retient sur les POST cross-site et les appels fetch. Ça bloque la plupart des attaques CSRF. None l’envoie partout et exige Secure, sinon le navigateur jette le cookie purement et simplement. Chrome et Edge traitent un cookie sans SameSite comme Lax ; Firefox et Safari ne le font pas, donc fixez-le explicitement.

localStorage et sessionStorage n’ont l’équivalent d’aucune de ces protections. Tout ce que vous y mettez est lisible par n’importe quel script qui tourne sur votre origine : votre propre code, une dépendance npm compromise, la charge utile d’un attaquant après une faille XSS. Les cookies ne sont pas plus sûrs par nature. Ils ont un mode optionnel que JavaScript ne peut pas toucher, et localStorage n’en a pas. C’est tout l’argument contre le fait de garder un token d’authentification dans localStorage.

Pourquoi les cookies ne partent pas avec un fetch cross-origin

Une page sur app.example.com appelle api.example.com avec fetch. Le cookie posé par api.example.com reste chez lui, même avec le bon domaine configuré sur le cookie, parce que fetch n’envoie les credentials qu’à la même origine par défaut. Il faut l’activer explicitement :

1
2
3

fetch("https://api.example.com/profile", {
  credentials: "include",
});

Le serveur doit coopérer aussi. Dès que les credentials entrent en jeu, il ne peut plus répondre avec le wildcard Access-Control-Allow-Origin: *. Il doit renvoyer l’origine précise et ajouter Access-Control-Allow-Credentials: true. C’est la négociation CORS couverte dans Qu’est-ce que CORS et Comment Résoudre les Erreurs CORS, et c’est là que vivent la plupart des bugs du genre « mon cookie n’arrive pas ».

Comment synchroniser localStorage entre les onglets avec l’événement storage

Quand localStorage change, le navigateur déclenche un événement storage dans chaque autre onglet de la même origine, pas dans l’onglet qui a fait le changement. Ça permet de déconnecter un utilisateur partout dès qu’un onglet appelle localStorage.removeItem("token") :

1
2
3
4
5

window.addEventListener("storage", (e) => {
  if (e.key === "token" && e.newValue === null) {
    window.location.href = "/login";
  }
});

sessionStorage ne déclenche jamais cet événement entre onglets. Aucun autre onglet ne peut le voir.

Quand ne pas utiliser les cookies, localStorage ou sessionStorage

Les cookies sont le mauvais choix pour tout ce qui dépasse quelques kilooctets, et pour les données que le serveur ne lit jamais, comme un thème d’interface ou un commentaire à moitié écrit. Vous le réexpédieriez à chaque requête pour rien.

localStorage est le mauvais choix pour tout ce qui doit survivre à une faille XSS : tokens de session, clés d’API, tout ce que vous détesteriez voir dans un rapport d’incident qui dit « l’attaquant a lancé console.log(localStorage) ». C’est aussi le mauvais choix pour des données sur lesquelles le serveur agit. Ça ne quitte jamais le navigateur sauf si votre code l’envoie, et une fois que vous avez écrit ce code, vous avez reconstruit un cookie sans HttpOnly, Secure ni SameSite.

sessionStorage est le mauvais choix pour tout ce qui doit être partagé entre onglets, ou qu’on s’attend à retrouver après que l’utilisateur a fermé puis réouvert le navigateur. Il correspond à un seul type de problème : un état qui appartient à cet onglet, pour cette visite. L’étape en cours d’un checkout multi-pages en est le cas classique, puisqu’elle ne doit pas fuiter dans un second onglet que l’utilisateur a ouvert pour comparer les prix.

Au-delà de quelques mégaoctets, ou dès que vous avez besoin de requêtes plutôt que de simples lookups par clé, aucun des trois ne convient. Passez à IndexedDB avant d’essayer de faire rentrer quelques milliers d’enregistrements JSON dans localStorage et de taper le quota.

Que choisir pour les tokens, le panier et les préférences

Si votre serveur doit s’y fier, mettez-le dans un cookie HttpOnly, Secure, avec un SameSite explicite. Réservez localStorage aux données que vous accepteriez de confier à n’importe quel script de votre page.

Articles associés

• Qu’est-ce que CORS et Comment Résoudre les Erreurs CORS
• Qu’est-ce que TLS et Comment Fonctionne le Chiffrement HTTPS
• Async/Await et l’Event Loop de JavaScript Expliqués