Sécurité des JSON Web Tokens : vulnérabilités courantes et corrections

Les JWT sont le standard de facto pour l'authentification API, mais leur simplicité apparente cache de véritables pièges de sécurité. Des JWT mal configurés ont conduit à des contournements d'authentification, des élévations de privilèges et des fuites de données. Ce guide couvre les vulnérabilités les plus critiques et comment les prévenir.

Rappel de la structure JWT

Un JWT se compose de trois parties encodées en Base64URL séparées par des points :

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJyb2xlIjoiYWRtaW4ifQ.signature

• Header : Algorithme et type de token
• Payload : Claims (données utilisateur, expiration, etc.)
• Signature : Vérification cryptographique

Inspectez la structure JWT avec notre Encodeur/Décodeur JWT.

Pour une compréhension fondamentale de la structure JWT, consultez notre guide Les tokens JWT expliqués.

Vulnérabilités critiques

1. Attaque par confusion d'algorithme

La vulnérabilité JWT la plus dangereuse. Si un serveur accepte le header alg du token sans validation, un attaquant peut :

Attaque : Changer l'algorithme de RS256 (asymétrique) à HS256 (symétrique) et signer le token falsifié avec la clé publique du serveur :

// Attacker's forged token
header: { "alg": "HS256", "typ": "JWT" }
payload: { "sub": "admin", "role": "superadmin" }
// Signed with the server's PUBLIC key as the HMAC secret

Si le serveur vérifie les tokens HS256 en utilisant la clé publique comme secret, le token falsifié passe la vérification.

Correction : Toujours spécifier l'algorithme attendu explicitement :

// WRONG - accepts whatever algorithm the token specifies
jwt.verify(token, key);

// CORRECT - enforce specific algorithm
jwt.verify(token, key, { algorithms: ['RS256'] });

2. Attaque de l'algorithme None

Certaines bibliothèques acceptent "alg": "none" — un token sans signature :

// Forged token with no signature
header: { "alg": "none", "typ": "JWT" }
payload: { "sub": "admin", "role": "superadmin" }
signature: ""  // empty

Correction : N'autorisez jamais l'algorithme none en production. Définissez explicitement la liste blanche des algorithmes autorisés.

3. Secrets de signature faibles

Les JWT basés sur HMAC (HS256/HS384/HS512) ne sont aussi forts que le secret :

// TERRIBLE - can be brute-forced in seconds
secret = "password123"

// WEAK - dictionary attack vulnerable
secret = "my-jwt-secret"

// STRONG - 256+ bits of randomness
secret = "a3f2b8c9d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0"

Correction : Utilisez au moins 256 bits d'aléa cryptographique pour les secrets HMAC. Mieux encore, utilisez des clés asymétriques (RS256, ES256) où la clé de signature n'a jamais besoin d'être partagée.

4. Expiration manquante

Les tokens sans expiration n'expirent jamais — un token volé accorde un accès permanent :

// WRONG - no expiration
{ "sub": "user123", "role": "admin" }

// CORRECT - short expiration
{
  "sub": "user123",
  "role": "admin",
  "exp": 1705312800,
  "iat": 1705309200,
  "nbf": 1705309200
}

Bonne pratique : Les tokens d'accès expirent en 15 à 60 minutes. Utilisez des tokens de rafraîchissement (stockés de manière sécurisée) pour les sessions longues.

5. Données sensibles dans le payload

Les payloads JWT sont encodés en Base64URL, pas chiffrés. N'importe qui peut les décoder :

echo "eyJzdWIiOiIxMjMiLCJyb2xlIjoiYWRtaW4ifQ" | base64 -d
# {"sub":"123","role":"admin"}

N'incluez jamais : Mots de passe, clés API, numéros de carte de crédit, données personnelles (numéro de sécurité sociale, dossiers médicaux) ou tout secret dans les payloads JWT.

6. Stockage des tokens (XSS vs CSRF)

Recommandé : Stockez les JWT dans des cookies HttpOnly, Secure, SameSite=Strict. Cela empêche l'accès JavaScript (défense XSS) et les requêtes cross-site (défense CSRF).

Set-Cookie: token=eyJ...; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=3600

Checklist de sécurité

1. Spécifiez explicitement les algorithmes — n'acceptez jamais celui du header du token
2. Rejetez l'algorithme none — exigez toujours une signature
3. Utilisez des secrets forts — 256+ bits pour HMAC, 2048+ bits pour RSA
4. Définissez une expiration courte — 15-60 minutes pour les tokens d'accès
5. Validez tous les claims — exp, iss, aud, nbf
6. Stockez dans des cookies HttpOnly — pas dans localStorage
7. Faites une rotation des secrets périodiquement — planifiez la rotation des clés
8. Ne stockez jamais de données sensibles dans le payload
9. Utilisez des clés asymétriques pour les systèmes distribués (RS256 ou ES256)
10. Implémentez la révocation de tokens — liste noire ou expiration courte + tokens de rafraîchissement

Signature asymétrique vs. symétrique

Recommandation : Utilisez ES256 (ECDSA) pour les nouvelles applications — il offre la sécurité asymétrique avec des performances proches du HMAC.

Stratégies de révocation de tokens

Les JWT sont sans état par conception — il n'y a pas de moyen intégré de les révoquer. Stratégies :

1. Expiration courte : Si les tokens expirent en 15 minutes, la fenêtre d'un token volé est limitée
2. Rotation des tokens de rafraîchissement : Émettre un nouveau token de rafraîchissement à chaque utilisation ; si un token est utilisé deux fois, révoquer tous les tokens
3. Liste noire : Stocker les identifiants des tokens révoqués (claims jti) et vérifier à chaque requête
4. Versioning des tokens : Inclure un numéro de version dans les claims ; incrémenter la version de l'utilisateur à la déconnexion

FAQ

Dois-je utiliser JWT ou les cookies de session pour l'authentification ?

Les cookies de session sont plus simples et plus sécurisés pour les applications web traditionnelles — le serveur contrôle le cycle de vie de la session, et la révocation est instantanée. Les JWT sont meilleurs pour les API sans état, les microservices et les applications mobiles où le stockage de session côté serveur n'est pas pratique. Si vous choisissez les JWT, implémentez les mesures de sécurité de ce guide.

Quel est le temps d'expiration idéal pour un JWT ?

Pour les tokens d'accès : 15-60 minutes. Plus court est plus sécurisé mais nécessite des rafraîchissements plus fréquents. Pour les tokens de rafraîchissement : 1-30 jours, stockés dans des cookies HttpOnly. Pour les tokens à usage unique (vérification d'e-mail, réinitialisation de mot de passe) : 1-24 heures.

Ressources associées

• Encodeur/Décodeur JWT — Inspectez et décodez les JWT en toute sécurité
• Les tokens JWT expliqués — Comprendre la structure et le flux JWT
• L'entropie des mots de passe expliquée — Robustesse des secrets de signature JWT