Un pentest signale que votre API accepte des JWT avec `alg: none`. Quel est l'impact et la correction ?

La sécurité d'un JWT repose entièrement sur sa signature. Le champ alg de l'en-tête indique au vérificateur quel algorithme a été utilisé — mais si le serveur fait confiance à ce champ et que none est autorisé, il saute entièrement la vérification de signature. Un attaquant envoie alors un jeton avec l'en-tête {"alg":"none"}, la charge utile de son choix (par exemple un sub différent ou un rôle admin) et une signature vide. Le serveur le considère comme valide.

Pourquoi c'est critique, pas cosmétique

C'est un contournement complet de l'authentification. L'attaquant n'a pas besoin de casser une clé ni de deviner un secret — il affirme simplement qui il est et le serveur le croit. Il peut usurper n'importe quel utilisateur, y compris des administrateurs, avec un jeton forgé en quelques secondes. C'est le résultat le plus grave qu'un système d'authentification puisse subir, donc l'option « faible impact, on documente » est dangereusement fausse.

La bonne correction

• Autoriser côté serveur une liste blanche des algorithmes attendus (par ex. uniquement RS256). Rejetez tout le reste, et rejetez explicitement none.
• Vérifier toujours la signature avec la bonne clé avant de lire la moindre revendication.
• Ne jamais laisser l'en-tête alg du jeton choisir la méthode de vérification. Découpler la confiance des entrées contrôlées par l'attaquant bloque aussi l'attaque de confusion d'algorithme, où un jeton passe de RS256 à HS256 afin que la clé publique soit détournée comme secret HMAC.

Pourquoi les distracteurs échouent

• Une expiration plus longue change la durée de vie d'un jeton légitime ; elle ne change rien pour des jetons jamais signés valablement.
• Déplacer le jeton dans un cookie affecte le transport et l'exposition XSS/CSRF, pas le fait qu'un jeton non signé forgé soit accepté.

Ce que l'examinateur cherche à évaluer

Si vous comprenez que la signature est l'ancre de confiance entière, savez expliquer clairement le contournement et optez pour une liste blanche d'algorithmes côté serveur avec vérification obligatoire — le jugement attendu d'un ingénieur AppSec senior.