Comment fonctionnent les JWT, et quels pièges de sécurité faut-il surveiller ?
Réponse courte
Un JWT comporte trois parties en base64url — en-tête, charge utile (revendications) et signature — réunies par des points. Le serveur signe l'en-tête et la charge utile avec un secret ou une clé privée, et vérifie cette signature à chaque requête pour faire confiance aux revendications sans état de session côté serveur. Pièges : accepter alg=none, la confusion de clés RS256 vers HS256, ne pas valider l'expiration/l'émetteur/l'audience, mettre des secrets dans la charge utile lisible, et l'absence de voie de révocation.
Les JWT reviennent constamment dans les entretiens appsec car ils sont faciles à utiliser et faciles à mal utiliser. Le recruteur veut confirmer que vous savez qu'ils sont signés, pas chiffrés, et que vous pouvez nommer les pièges classiques d'implémentation.
Comment un JWT est structuré
Un JWT a trois parties encodées en base64url séparées par des points : un en-tête (algorithme et type de jeton), une charge utile de revendications (sujet, expiration, émetteur, audience, rôles) et une signature. Le serveur crée la signature sur l'en-tête et la charge utile à l'aide soit d'un secret partagé (HS256), soit d'une clé privée (RS256). À chaque requête, il recalcule/vérifie cette signature ; si elle est valide, les revendications peuvent être considérées comme fiables sans recherche de session côté serveur. Cette absence d'état est l'attrait — et la source de la plupart des problèmes.
Les pièges
alg=none. Certaines bibliothèques honoraient historiquement un en-tête revendiquant « aucune signature », laissant un attaquant retirer la signature et forger n'importe quelle revendication. Fixez toujours l'algorithme attendu côté serveur plutôt que de faire confiance à l'en-tête.- Confusion de clés (RS256 → HS256). Si le serveur utilise la clé publique RSA comme secret HMAC, un attaquant peut signer un jeton forgé avec cette clé publique. Rejetez le changement d'algorithme.
- Validation de revendications manquante. Une signature prouve seulement que le jeton n'a pas été altéré — vous devez toujours vérifier l'expiration (
exp), l'émetteur (iss) et l'audience (aud). Les jetons sans expiration vivent éternellement. - Le traiter comme confidentiel. La charge utile n'est que du base64, entièrement lisible. N'y mettez jamais de secrets.
- Aucune révocation. Comme les JWT sont sans état, un jeton volé reste valide jusqu'à son expiration. Utilisez de courtes durées de vie avec des jetons de rafraîchissement, ou une liste de refus pour les urgences.
Ce que recherchent les recruteurs
La structure en-tête/charge utile/signature, « signé, pas chiffré », la fixation explicite de l'algorithme pour tuer alg=none et la confusion de clés, la validation de exp/iss/aud, et la conscience que la révocation est la partie difficile des jetons sans état.
Questions de suivi probables
- Pourquoi la vulnérabilité alg=none est-elle si dangereuse et comment la prévenir ?
- Comment la confusion de clés RS256 vers HS256 permet-elle à un attaquant de forger des jetons ?
- Comment révoquer un JWT sans état avant son expiration ?