Réinitialisation de mot de passe : les 7 erreurs qui ouvrent vos comptes
Le maillon faible de l'authentification
Vous avez soigné votre login : mots de passe hashés en bcrypt, MFA disponible, rate limiting en place. Mais le flow « mot de passe oublié » contourne tout ça par construction : il permet de prendre le contrôle d'un compte sans connaître le mot de passe. C'est pour ça que les attaquants le testent en premier — et que nous aussi.
Voici les 7 erreurs que nous rencontrons le plus souvent, de la plus grave à la plus subtile.
1. Token prévisible ou trop court
Un token de reset construit à partir d'un timestamp, d'un ID utilisateur encodé en base64, ou d'un UUID v1 (qui contient le timestamp et l'adresse MAC) peut être deviné ou forcé. Il faut au minimum 128 bits d'entropie issus d'un générateur cryptographique (crypto.randomBytes, pas Math.random()).
2. Token sans expiration
Un lien de reset envoyé il y a 6 mois qui fonctionne encore, c'est un lien de plus qui traîne dans une boîte mail compromise. Durée de vie maximale recommandée : 15 à 60 minutes.
3. Token non invalidé après usage
Le token doit être à usage unique. S'il reste valide après le changement de mot de passe, un attaquant qui a intercepté l'email peut re-réinitialiser le compte après coup. Même exigence : invalider tous les tokens précédents quand un nouveau est demandé.
4. Host header injection
L'erreur la plus élégante. Si votre backend construit le lien de reset à partir du header Host de la requête, un attaquant demande un reset pour la victime en envoyant Host: attaquant.fr. La victime reçoit un email légitime… avec un lien pointant vers le domaine de l'attaquant, token inclus. Le lien doit être construit à partir d'une URL de base définie en configuration, jamais depuis la requête.
5. Énumération d'utilisateurs
« Aucun compte associé à cette adresse » vs « Email envoyé » : cette différence de message permet de constituer une liste des clients de votre SaaS. Réponse identique dans les deux cas, temps de réponse compris.
6. Sessions non révoquées après le reset
Le scénario : un attaquant a déjà une session active sur le compte (mot de passe fuité, session volée). La victime change son mot de passe en pensant le chasser… mais la session de l'attaquant reste valide. Tout changement de mot de passe doit révoquer toutes les sessions et refresh tokens existants.
7. Pas de rate limiting sur la demande de reset
Sans limite, la fonction devient un canon à spam qui bombarde vos utilisateurs — et un outil de test massif des erreurs 1 à 5.
Checklist
Ces 7 points font partie des vérifications systématiques de notre Premier diagnostic : en 48h, en conditions réelles, sans accès à votre code.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Firebase Firestore : pourquoi 'allow read, write: if request.auth != null' n'est pas une sécurité
La règle d'authentification basique de Firestore ne protège pas vos données. Voici pourquoi et comment corriger.
WordPress 6.8 : ce que le passage a bcrypt change vraiment pour la securite
WordPress 6.8 a remplace phpass par bcrypt pour les mots de passe utilisateurs et introduit BLAKE2b pour plusieurs secrets applicatifs. Voici ce que cela change vraiment, et ce que cela ne corrige pas.
CVE-2026-32541 : contournement du middleware Next.js — analyse et correction
Une vulnérabilité critique dans le middleware Next.js permettait de contourner l'authentification. Analyse technique de la faille et guide de correction pour les SaaS RH.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.