flawopen.com/Référence/JWT vs cookies HttpOnly
JWT dans localStorage ou cookies HttpOnly : lequel est plus sûr ?
Pour de nombreuses applications web, une session gérée côté serveur et transmise dans un cookie HttpOnly constitue un bon choix par défaut. JavaScript ne peut pas lire ce cookie, ce qui limite l’extraction du jeton, mais ne neutralise pas les XSS : un script injecté de même origine peut toujours envoyer des requêtes authentifiées et lire les données accessibles à la page.
Les compromis de sécurité
| Stockage / transmission | Exposition aux XSS | Comportement CSRF | Révocation |
|---|---|---|---|
localStorage bearer token | JavaScript de même origine peut le lire ; une XSS peut le voler ou agir comme l’utilisateur. | Pas ajouté automatiquement aux requêtes intersites ; XSS et CSRF côté client restent possibles. | Un JWT autonome peut rester valide jusqu’à expiration sans vérification de révocation. |
HttpOnly cookie | JavaScript ne peut pas lire la valeur ; une XSS peut encore envoyer des requêtes authentifiées. | Envoyé automatiquement selon les règles des cookies ; SameSite n’est qu’une protection CSRF. | Une session opaque peut être invalidée côté serveur ; un JWT en cookie exige sa propre politique. |
Architecture recommandée
- ✓Stockez les identifiants de session dans des cookies
HttpOnly; Secure; SameSite=Lax. - ✓Évitez de stocker des jetons d'authentification persistants dans
localStorageousessionStorage.
Distinguer format du jeton, stockage et état de session
JWT est un format de jeton ; localStorage et les cookies sont des mécanismes de stockage et de transmission du navigateur. Un JWT peut être stocké dans l’un ou l’autre. Un identifiant de session opaque dans un cookie désigne généralement un état conservé côté serveur. « JWT ou cookie » n’est pas une comparaison directe entre options équivalentes.
Ce que chaque choix change
Le navigateur n’ajoute pas automatiquement les valeurs de localStorage aux requêtes intersites, mais une XSS de même origine peut lire un jeton bearer ou agir via l’application. Les cookies sont envoyés selon les règles du navigateur ; HttpOnly masque leur valeur à JavaScript sans empêcher un script injecté d’utiliser la page authentifiée. SameSite=Lax est une couche CSRF, pas une garantie complète : les navigations de premier niveau avec méthode sûre et les requêtes same-site restent pertinentes. Ne modifiez pas l’état via GET et utilisez une défense CSRF adaptée, comme des jetons validés et/ou la vérification d’Origin.
La révocation dépend de l’état serveur et de la validation du jeton, pas de son emplacement de stockage. Une session côté serveur peut être invalidée en supprimant son enregistrement. Un JWT autonome peut rester accepté jusqu’à expiration sans vérification de révocation ; une durée courte réduit cette fenêtre sans la supprimer.
Point de départ pratique
- ✓Pour une application web propriétaire, privilégiez une session opaque côté serveur ou un Backend-for-Frontend (BFF) si cela convient.
- ✓Configurez les cookies de session avec
Secure,HttpOnly, unSameSitechoisi délibérément,Path=/et, si possible, sansDomain; envisagez__Host-. - ✓Utilisez des jetons CSRF et/ou la validation d’Origin pour les requêtes qui modifient l’état ; ne modifiez jamais l’état via
GET. - ✓Si des JWT dans le navigateur sont nécessaires, limitez leur durée, définissez la révocation/déconnexion et prévenez les XSS. Le cookie ne remplace pas les contrôles d’autorisation.