Les JWT ne sont pas le véritable argument ici. La stratégie de stockage dans le navigateur l'est. Les équipes stockent souvent des tokens d'accès dans localStorage parce qu'il est facile de les connecter au code client. Le problème est simple : si une attaque XSS réussit, le token est généralement lisible immédiatement.
Les cookies HttpOnly modifient ce profil de risque. Le navigateur peut envoyer automatiquement le token de session, mais le JavaScript normal ne peut pas le lire.
Pourquoi les Cookies Sont Généralement Plus Sûrs dans le Navigateur
Un cookie de session sécurisé ressemble souvent à ceci :
Set-Cookie: session=opaque-token; HttpOnly; Secure; SameSite=Lax; Path=/
Cela ne rend pas le système invulnérable. Cela supprime l'un des chemins d'exfiltration de tokens les plus simples dans les applications navigateur.
Les Équilibres que Vous Devez Toujours Gérer
Déplacer le token dans un cookie change le modèle de menace, mais pas le besoin de mesures de sécurité :
- Les défenses CSRF restent importantes
- La rotation de session reste importante
- L'XSS est toujours sérieux car un attaquant peut agir à travers la page même s'il ne peut pas lire le token
Le point n'est pas "les cookies résolvent l'authentification". Le point est que le transport de session géré par le navigateur est généralement plus sûr que de remettre des tokens porteurs à localStorage.
Meilleure Règle
Pour les applications basées sur le navigateur, privilégiez les cookies HttpOnly à moins d'avoir une raison impérieuse de ne pas le faire. N'envisagez des conceptions de tokens en JavaScript que lorsque l'architecture client en a vraiment besoin et que le compromis de sécurité est bien compris.
Lectures Complémentaires