🛡️ Module 5 — Sécurité : pièges classiques et bonnes pratiques

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 ⏱️ Temps de lecture estimé : 8 minutes

Ce dernier module rassemble les pièges réellement observés au Module 4 — ce ne sont pas des mises en garde abstraites, vous venez de reproduire chacune de ces failles avec du code qui tourne.

🚫 Piège n°1 — Faire confiance au `alg` du token

C’est la faille alg: none du Module 4 : si votre code de vérification lit l’algorithme depuis le token plutôt que de l’imposer, un attaquant choisit lui-même comment son propre token sera « vérifié ».

# ❌ DANGEREUX : l'algorithme vient du token lui-même
alg = jwt.get_unverified_header(token)["alg"]
jwt.decode(token, key, algorithms=[alg])

# ✅ CORRECT : l'algorithme attendu est fixé par le serveur, jamais par le token
jwt.decode(token, key, algorithms=["RS256"])

🚫 Piège n°2 — Mélanger HS256 et RS256 sur le même service

Nous l’avons vu au Module 4 : si un serveur accepte indifféremment HS256 et RS256 avec la même clé, la clé publique RS256 (publique par définition !) peut potentiellement servir de secret HMAC. PyJWT s’en protège nativement, mais toutes les bibliothèques/langages ne le font pas — n’acceptez qu’un seul algorithme par service, jamais une liste « au cas où ».

🚫 Piège n°3 — Mettre des données sensibles dans le payload

Rappel du Module 2 : le payload n’est pas chiffré, juste encodé en Base64URL — n’importe qui peut le décoder en trois lignes de Python. Un mot de passe, un numéro de carte, une donnée médicale… jamais dans un JWT standard.

🚫 Piège n°4 — Où stocker le token côté client ?

Emplacement	Risque principal	Verdict
`localStorage` / `sessionStorage`	Accessible en JavaScript → vulnérable au XSS : un script malveillant injecté peut lire le token et l’exfiltrer	⚠️ À éviter pour un token sensible
Cookie httpOnly + Secure + SameSite=Strict	Inaccessible en JavaScript (donc protégé du XSS), mais envoyé automatiquement par le navigateur → nécessite une protection CSRF	✅ Recommandé pour une application web classique
Mémoire (variable JS, jamais persistée)	Perdu au rafraîchissement de la page	✅ Bon compromis pour un access token très court, combiné à un refresh token en cookie httpOnly

Il n’y a pas de choix parfait — seulement des compromis. Le point commun des bonnes pratiques : minimiser la fenêtre d’exposition du token en JavaScript.

🚫 Piège n°5 — Croire qu’on peut « déconnecter » un JWT

Contrairement à une session serveur qu’on peut supprimer instantanément, un JWT signé reste valide jusqu’à expiration, quoi qu’il arrive — le serveur n’a par définition rien à « effacer ». Si un token est volé, il reste utilisable jusqu’à exp.

Deux parades complémentaires :

Durée de vie courte pour l’access token (quelques minutes) + un refresh token révocable, stocké côté serveur (voir Module 3).
Liste de révocation (denylist) pour les cas critiques (déconnexion volontaire, compromission détectée) : une petite base — souvent un cache rapide comme Redis — des identifiants de tokens (jti, un claim standard prévu pour ça) explicitement invalidés avant leur expiration naturelle. Cela réintroduit un aller-retour réseau, mais seulement pour les cas où c’est nécessaire, pas à chaque requête.

🚫 Piège n°6 — Un secret HS256 trop faible

Le secret HS256 est la seule chose qui protège vos tokens : un secret court, un mot du dictionnaire, ou une valeur codée en dur oubliée dans un dépôt Git rend une falsification triviale (attaque par force brute hors-ligne). Utilisez un secret long et aléatoire (32 octets ou plus), généré une fois, stocké dans un gestionnaire de secrets — jamais dans le code source.

✅ Check-list avant un déploiement réel

Point de contrôle	Pourquoi
L’algorithme de vérification est fixé côté serveur, jamais lu depuis le token	Empêche la faille `alg: none` (Module 4)
Un seul algorithme accepté par service (pas de mélange HS256/RS256)	Empêche la confusion d’algorithme (Module 4)
`exp` est présent et court pour les access tokens	Limite la fenêtre d’exploitation d’un token volé
Le payload ne contient aucune donnée sensible	Le payload est lisible par n’importe qui
Le token est transmis uniquement en HTTPS	Un JWT intercepté en clair est aussi valide qu’un mot de passe volé
Stockage client réfléchi (httpOnly+Secure+SameSite plutôt que localStorage quand c’est possible)	Réduit l’exposition au XSS
Un mécanisme de refresh token révocable existe	Un JWT seul ne peut jamais être « déconnecté » avant expiration
Le secret HS256 (ou la clé privée RS256) est long, aléatoire, hors du code source	Un secret faible rend toute signature falsifiable

🎓 Conclusion du cours

Ce cours a suivi un principe simple : ne jamais affirmer une bonne pratique sans en avoir d’abord observé la raison d’être. Vous avez vu, avec du code réellement exécuté :

Ce qu’un JWT contient et pourquoi il n’est jamais un secret (Module 2),
Comment il circule dans une architecture réelle (Module 3),
Pourquoi falsifier un token échoue, et comment une vraie faille historique (alg: none) fonctionnait (Module 4),
Ce qui reste fragile malgré tout ça, et comment le compenser (ce module).

Le JWT n’est ni une solution magique ni un piège à éviter : c’est un outil avec des compromis précis — rapide et sans état, au prix d’une révocation plus difficile qu’une session classique. Choisissez-le en connaissance de cause. 🎯