Le JWT (JSON Web Token) est devenu le standard de fait de l'authentification moderne : API REST, architectures microservices, SSO, applications mobiles. Sa simplicité apparente cache pourtant une réalité que trop d'équipes techniques ignorent : un JWT n'est pas un jeton chiffré, c'est un jeton signé. Toute personne interceptant un JWT peut en lire le contenu intégral sans effort. Et si la vérification de sa signature est mal implémentée, un attaquant peut tout simplement le falsifier.
Une attaque JWT réussie ne se limite jamais à un incident technique isolé. Elle permet le plus souvent à un attaquant de se faire passer pour n'importe quel utilisateur, y compris un administrateur, et d'obtenir un accès complet à une application ou une API sans avoir besoin du moindre mot de passe. Pour un RSSI, comprendre ce risque n'est pas une option : c'est une condition de la sécurité de toute architecture reposant sur ce mécanisme d'authentification.
Cet article détaille comment fonctionne un JWT, les techniques d'attaque les plus courantes contre ce format, comment un attaquant les exploite concrètement pour compromettre une organisation, et les recommandations que l'équipe Piirates met en œuvre lors de ses missions de test d'intrusion pour sécuriser durablement vos jetons d'authentification.
Qu'est-ce qu'un JWT ? Anatomie d'un jeton d'authentification
Un JWT (JSON Web Token) est une chaîne de caractères composée de trois parties encodées en base64url et séparées par des points : un en-tête, une charge utile (payload) et une signature. L'en-tête précise l'algorithme de signature utilisé (typiquement HS256, RS256 ou ES256) ainsi que le type de jeton. Le payload contient les claims, c'est-à-dire les informations portées par le jeton : identifiant de l'utilisateur, rôle, date d'expiration, émetteur, et tout claim métier ajouté par l'application.
La signature est calculée en appliquant l'algorithme désigné dans l'en-tête à l'en-tête et au payload concaténés, à l'aide d'un secret partagé (pour HS256) ou d'une clé privée (pour RS256 et ES256). Cette signature garantit l'intégrité du jeton : elle prouve qu'il n'a pas été modifié depuis son émission par le serveur.
Un point est trop souvent mal compris, y compris par des développeurs expérimentés : le base64url n'est pas un chiffrement, c'est un simple encodage. N'importe qui peut décoder l'en-tête et le payload d'un JWT en quelques secondes, sans clé ni mot de passe. Seule la signature protège l'intégrité du contenu, jamais sa confidentialité. C'est cette confusion entre signature et chiffrement qui est à l'origine de la majorité des vulnérabilités JWT observées en test d'intrusion.
Pourquoi le JWT est devenu la cible privilégiée des attaquants
Le JWT s'est imposé dans les architectures modernes car il permet une authentification sans état (stateless) : le serveur n'a pas besoin de conserver de session en mémoire, il lui suffit de vérifier la signature du jeton présenté à chaque requête. Cette propriété, précieuse pour les API REST et les architectures en microservices, explique sa présence quasi systématique dans les applications SaaS, les back-ends mobiles et les systèmes d'authentification unique (SSO).
Cette omniprésence en fait une cible de choix. Chaque application implémentant elle-même sa logique de vérification de signature introduit un risque d'erreur, et ces erreurs se répètent d'une organisation à l'autre car elles proviennent souvent d'une mauvaise compréhension du fonctionnement réel du format, plutôt que d'un manque de compétence isolé. C'est précisément ce qui rend le sujet stratégique pour un RSSI : une vulnérabilité JWT n'est presque jamais un problème de code isolé, c'est un problème d'architecture d'authentification qui touche potentiellement l'ensemble d'un système d'information.
Toutes nos missions sont spécifiques
Parce que vos enjeux le sont !
Le test d'intrusion est avant tout une philosophie qui, couplé avec nos compétences techniques multiples peut s'adapter aux diffférentes cibles.
Les techniques d'attaque JWT les plus courantes
Une attaque JWT ne cherche jamais à casser la cryptographie sous-jacente. Elle exploite presque toujours une erreur dans la façon dont le serveur vérifie la signature ou fait confiance aux informations contenues dans le jeton. Voici les techniques que l'équipe Piirates rencontre le plus fréquemment lors de ses missions.
L'attaque alg:none, supprimer purement et simplement la signature
La spécification JWT prévoit une valeur d'algorithme none, initialement destinée à des cas d'usage où la signature n'est pas nécessaire. Certaines bibliothèques historiques acceptaient cette valeur sans restriction. Un attaquant modifie alors l'en-tête du jeton pour indiquer alg:none, supprime la signature, et si le serveur ne vérifie pas explicitement que l'algorithme reçu correspond à celui attendu, le jeton falsifié est accepté comme valide, avec n'importe quel contenu de payload choisi par l'attaquant.
La confusion d'algorithme entre RS256 et HS256
De nombreuses architectures utilisent RS256, un algorithme asymétrique où le serveur possède une clé privée pour signer et expose une clé publique pour vérifier. Cette clé publique est souvent accessible sans restriction, par exemple via un endpoint JWKS. Si le code de vérification du serveur se contente de lire l'algorithme indiqué dans l'en-tête du jeton reçu plutôt que d'imposer l'algorithme attendu, un attaquant peut signer un jeton falsifié avec l'algorithme symétrique HS256, en utilisant la clé publique RSA (qu'il peut librement récupérer) comme secret HMAC. Le serveur, trompé par l'en-tête du jeton, vérifie alors la signature avec cette même clé publique utilisée comme secret partagé, et valide un jeton entièrement contrôlé par l'attaquant.
Le brute force de la clé secrète HS256
Lorsque le secret utilisé pour signer des jetons HS256 est trop court, prévisible ou dérivé d'un mot commun, il devient possible de le retrouver hors ligne par force brute à partir d'un jeton légitime intercepté. Une fois ce secret découvert, l'attaquant peut signer lui-même n'importe quel jeton, avec n'importe quel rôle ou identifiant, sans plus jamais interagir directement avec le serveur pour deviner le secret.
L'injection via l'en-tête kid (Key ID)
L'en-tête kid indique au serveur quelle clé utiliser pour vérifier la signature, ce qui permet la rotation de clés multiples. Si le serveur construit un chemin de fichier, une requête en base de données ou une commande à partir de la valeur de ce champ sans la valider strictement, un attaquant peut manipuler ce champ pour pointer vers une ressource qu'il contrôle ou dont le contenu est prévisible, par exemple un fichier vide interprété comme secret de valeur nulle, ce qui lui permet ensuite de signer un jeton falsifié avec cette valeur connue.
L'injection via jku ou x5u, une clé de vérification hébergée par l'attaquant
Les en-têtes jku et x5u permettent d'indiquer une URL où récupérer la clé publique ou le certificat nécessaire à la vérification du jeton. Si le serveur va chercher cette clé à l'adresse indiquée dans le jeton sans vérifier que le domaine appartient à une liste de confiance, un attaquant peut héberger sa propre paire de clés, signer un jeton falsifié avec sa clé privée, et indiquer dans l'en-tête jku l'URL de sa propre clé publique. Le serveur récupère alors cette clé contrôlée par l'attaquant et valide un jeton entièrement forgé.
L'absence d'expiration et de révocation
Un jeton sans claim d'expiration, ou avec une durée de vie excessive, reste valide bien au-delà du temps nécessaire à une session légitime. Combiné à l'absence de mécanisme de révocation, un jeton volé lors d'un incident, par exemple via une faille XSS, reste utilisable par l'attaquant jusqu'à sa date d'expiration théorique, parfois plusieurs mois plus tard, sans qu'aucune action côté serveur ne puisse l'invalider.
Anatomie d'une attaque JWT, étape par étape
Pour bien comprendre l'impact réel de ces failles, voici comment une attaque JWT se déroule concrètement lors d'un test d'intrusion, depuis la première interception jusqu'à la compromission complète d'une application.
Étape 1 : Interception et décodage du jeton
Tout commence par la récupération d'un jeton légitime, intercepté sur le réseau, extrait du stockage local du navigateur, ou obtenu via une session de test authentifiée. Le décodage de l'en-tête et du payload ne demande aucun outil sophistiqué : un simple décodage base64 révèle immédiatement l'algorithme utilisé et l'ensemble des claims, y compris souvent des informations censées rester internes comme l'identifiant technique d'un utilisateur ou son rôle.
Étape 2 : Identification de la faiblesse exploitable
L'attaquant teste ensuite systématiquement les scénarios connus : modification de l'algorithme en none, tentative de confusion RS256 vers HS256 si l'application expose sa clé publique, test de brute force du secret si l'algorithme est HS256. Cette phase, largement automatisable, permet d'identifier en quelques minutes si l'implémentation du serveur est vulnérable.
⚠ Une clé publique RS256 exposée sur un endpoint JWKS public, combinée à une vérification de signature qui fait confiance à l'algorithme indiqué dans le jeton, permet de forger un jeton administrateur valide en quelques secondes, sans jamais avoir eu accès au moindre mot de passe.
Étape 3 : Forge d'un jeton falsifié avec des privilèges élevés
Une fois la faiblesse confirmée, l'attaquant modifie le payload du jeton pour s'attribuer un rôle administrateur, un identifiant d'utilisateur privilégié, ou tout claim métier déterminant les autorisations applicatives. Il resigne ensuite ce jeton falsifié en exploitant la faiblesse identifiée, sans jamais avoir besoin de connaître le mot de passe d'un compte réel.
Étape 4 : Élévation de privilèges et accès aux données
Ce jeton falsifié est ensuite présenté à l'API cible comme s'il s'agissait d'une authentification légitime. Si l'application ne réalise aucun contrôle d'autorisation indépendant de la simple présence d'un claim dans le jeton, l'attaquant accède directement aux fonctionnalités et aux données réservées aux comptes à privilèges, y compris dans des architectures en microservices où ce même jeton falsifié peut être réutilisé auprès de plusieurs services internes.
Étape 5 : Persistance et mouvement latéral
Dans une architecture où le jeton n'expire jamais ou n'est jamais révocable, l'attaquant conserve un accès prolongé, bien après la découverte de l'intrusion initiale. Ce jeton falsifié devient alors un point d'accès durable pour explorer d'autres services internes exposés derrière la même authentification, ce qui transforme une faille de vérification isolée en compromission étendue du système d'information.
Ce que ce type d'attaque signifie concrètement pour un RSSI
Une vulnérabilité JWT ne se traduit pas par un incident mineur limité à une seule fonctionnalité. Parce que le JWT sert de socle d'authentification transversal, une faille dans sa vérification remet en cause la confiance accordée à l'ensemble des échanges entre les services qui s'appuient dessus. Dans une architecture en microservices, un seul point de vérification mal implémenté peut suffire à compromettre l'authentification de tout un écosystème applicatif, bien au-delà du service initialement visé par l'attaquant.
C'est pourquoi l'audit de l'implémentation JWT constitue un point de contrôle prioritaire dans les missions de test d'intrusion menées par Piirates sur les applications web, les API et les architectures SSO, quel que soit le secteur d'activité de l'organisation concernée.
Les recommandations Piirates pour sécuriser vos JWT
1. Imposer explicitement l'algorithme attendu côté serveur. Ne jamais dériver l'algorithme de vérification depuis l'en-tête du jeton reçu : le serveur doit toujours vérifier avec l'algorithme qu'il attend, jamais celui que l'attaquant a choisi d'annoncer.
2. Bannir totalement l'algorithme none. Aucune configuration légitime ne justifie d'accepter un jeton sans signature vérifiée en production.
3. Privilégier des algorithmes asymétriques comme RS256 ou ES256 pour toute architecture multi-services, en gardant la clé privée strictement confinée au service émetteur des jetons.
4. Si HS256 est utilisé, imposer un secret long et aléatoire, généré par un gestionnaire de secrets, d'au moins 256 bits d'entropie, avec une politique de rotation régulière.
5. Restreindre strictement les en-têtes kid, jku et x5u. Valider que jku pointe uniquement vers un domaine de confiance en liste blanche, ne jamais résoudre kid vers un chemin de fichier ou une requête construite dynamiquement sans validation stricte.
6. Réduire la durée de vie des jetons d'accès à quelques minutes et s'appuyer sur des refresh tokens révocables, stockés et contrôlés côté serveur.
7. Mettre en place un mécanisme de révocation effectif, via une liste noire, un service d'introspection centralisé, ou un suivi du claim jti en base de données.
8. Valider systématiquement l'ensemble des claims (iss, aud, exp, nbf) à chaque vérification, et pas uniquement l'intégrité de la signature.
9. Ne jamais placer de donnée sensible en clair dans le payload, visible par simple décodage base64 : privilégier des références internes ou recourir à un chiffrement JWE si la confidentialité du contenu est requise.
10. Utiliser des bibliothèques JWT maintenues et à jour, configurées de façon stricte, avec une liste blanche d'algorithmes autorisés définie explicitement dans le code.
11. Superviser les tentatives de vérification échouées et les usages anormaux de jetons dans le SIEM, un pic de rejets de signature étant souvent le premier signal d'une tentative d'exploitation en cours.
Cadre légal et éthique du test des mécanismes JWT
Tester la robustesse de l'implémentation JWT d'une organisation implique de manipuler activement des mécanismes d'authentification réels. Cette démarche n'est légale que dans le cadre strict d'un test d'intrusion autorisé, avec un périmètre et une fenêtre temporelle définis contractuellement avec le client. En dehors de ce cadre, forger ou falsifier un jeton d'authentification pour accéder à un système constitue un accès frauduleux à un système de traitement automatisé de données, une infraction prévue par l'article 323-1 du Code pénal en France.
L'approche Piirates, la vérification JWT comme point de contrôle systématique
Chez Piirates, l'analyse de l'implémentation JWT fait partie des contrôles systématiquement intégrés à chaque test d'intrusion portant sur une application web, une API ou un système d'authentification unique. L'objectif n'est jamais de constater une faiblesse théorique, mais de démontrer concrètement, dans le contexte réel de l'organisation, l'impact d'une mauvaise vérification de signature sur l'ensemble du système d'information.
Pour un RSSI, cette approche a un avantage direct : elle transforme une question technique souvent mal comprise en une évaluation concrète du risque, assortie de recommandations directement actionnables par les équipes de développement. C'est cette exigence de démonstration et de pédagogie qui structure chaque mission Piirates portant sur les mécanismes d'authentification par jeton.
Sécuriser vos jetons JWT
Ce que nous ne faisons pas
(Liste non exhaustive)
Piratage de boite mail
Piratage comptes réseaux sociaux
Espionnage
Exfiltration de sms
Récupération de Cryptomonnaies
Prise en main à distance de véhicules
Suivi GPS de véhicule
Envoyez nous un ping
Une attaque JWT consiste à exploiter une erreur dans la façon dont un serveur vérifie la signature ou fait confiance au contenu d'un jeton JSON Web Token, afin de le falsifier ou de le contourner. L'attaquant ne casse jamais la cryptographie elle-même : il exploite une mauvaise implémentation de la vérification, comme l'acceptation de l'algorithme none ou une confusion entre algorithmes symétrique et asymétrique.
Non. Un JWT standard est encodé en base64url et signé, jamais chiffré. N'importe qui interceptant le jeton peut décoder l'en-tête et le payload en clair, sans clé ni mot de passe. Seule la signature garantit que le contenu n'a pas été modifié, elle ne garantit jamais sa confidentialité. Si des données sensibles doivent rester confidentielles, il faut recourir à un chiffrement additionnel (JWE) ou éviter de les placer dans le jeton.
La méthode la plus fiable consiste à faire réaliser un test d'intrusion ciblant spécifiquement l'implémentation de la vérification des jetons : tentative d'algorithme none, test de confusion RS256/HS256, contrôle de la robustesse du secret, et validation des en-têtes kid, jku et x5u. Un audit de code de la fonction de vérification côté serveur complète utilement cette approche, notamment pour vérifier que l'algorithme attendu est bien imposé et non dérivé du jeton reçu.
Non, ce n'est pas le format JWT en lui-même qui est en cause, mais la façon dont il est implémenté. Un JWT correctement configuré, avec un algorithme imposé côté serveur, une gestion rigoureuse des clés et une durée de vie courte, reste un mécanisme d'authentification robuste et parfaitement adapté aux architectures modernes. L'enjeu est de sécuriser son implémentation, pas de renoncer au format.
Comment un attaquant exploite les failles JWT pour compromettre une organisation, et les recommandations Piirates pour sécuriser vos JSON Web Token.
