Comment tester les emails de réinitialisation de mot de passe de bout en bout

Commencer par deux cas de demande publique

Créez un utilisateur connu dont l’adresse est un nouveau destinataire InboxTap, puis soumettez une demande de réinitialisation pour ce compte. Soumettez le même formulaire public avec une autre adresse inconnue et comparez le code d’état HTTP et la réponse présentée à l’utilisateur.

Le point de terminaison ne doit pas révéler l’existence d’un compte. Évitez d’exiger des durées exactement égales dans une suite navigateur : l’ordonnancement et la base de données rendent cette assertion fragile. Appuyez-vous plutôt sur les recommandations de sécurité du fournisseur et sur des tests ciblés de plus bas niveau pour les protections contre les attaques temporelles.

• Fiche OWASP sur les mots de passe oubliés ↗

Valider la destination de réinitialisation

Attendez une URL contenant le chemin de réinitialisation de l’application, puis analysez-la avant de naviguer. Comparez exactement l’origine et le chemin attendus afin qu’une URL de base erronée, un hôte non fiable ou un mauvais rappel ne puisse pas être masqué par une redirection du navigateur.

Traitez l’URL complète comme un identifiant secret. Ne l’affichez pas, ne l’insérez pas dans le nom du test et ne joignez pas une capture d’écran non masquée qui expose la barre d’adresse.

await requestPasswordReset(inbox.address);

const rawUrl = await inbox.waitForLink({
  contains: "/reset-password",
  timeoutMs: 20_000,
});

const resetUrl = new URL(rawUrl);
expect(resetUrl.origin).toBe(appOrigin);
expect(resetUrl.pathname).toBe("/reset-password");

await completePasswordReset(resetUrl.href, newPassword);
expect(await signIn(inbox.address, oldPassword)).toBe(false);
expect(await signIn(inbox.address, newPassword)).toBe(true);

Prouver le remplacement du mot de passe

Remplissez le véritable formulaire de réinitialisation avec un mot de passe conforme à la politique actuelle de l’application. Déconnectez-vous ensuite ou créez un contexte navigateur vierge, confirmez que l’ancien mot de passe échoue, puis que le nouveau authentifie le même compte.

Contrôlez l’identité ou l’état de session provenant du serveur au lieu de vous fier uniquement à une bannière de réussite. Vérifiez aussi le refus d’un nouveau mot de passe faible ou dont la confirmation diffère lorsque cette logique appartient à la page de réinitialisation.

Rejeter la réutilisation, l’expiration et l’altération

Tentez de réutiliser l’URL déjà consommée et vérifiez qu’elle ne peut pas changer une nouvelle fois le mot de passe. Exercez un jeton expiré avec une horloge maîtrisée ou une durée propre au test, puis modifiez le jeton pour prouver le rejet des entrées mal formées.

L’échec ne doit exposer ni le jeton, ni les détails internes de la politique de mot de passe, ni les informations du compte dans la page ou les journaux courants du serveur. L’utilisateur peut recevoir un chemin sûr pour demander une nouvelle réinitialisation.

Vérifier la politique de session

Décidez si une réinitialisation révoque toutes les sessions existantes, uniquement les autres sessions, ou aucune. Better Auth, par exemple, expose revokeSessionsOnPasswordReset au lieu d’imposer le même résultat à toutes les applications.

Créez les sessions antérieures nécessaires et inspectez-les après le changement. InboxTap ne peut pas déduire cette politique de l’email ; elle doit être vérifiée auprès du système d’authentification.

• Documentation Better Auth sur l’email de réinitialisation ↗

Séparer la livraison de la déduplication métier

Utilisez toHaveDeliveredOnce() après avoir confirmé l’existence du premier message de réinitialisation lorsque le produit promet une livraison par demande. Sa fenêtre d’observation facultative peut détecter une nouvelle tentative immédiate, mais ne prouve pas qu’aucune tâche ultérieure ne s’exécutera.

La persistance de la file, les clés d’idempotence, la limitation de débit et la déduplication relèvent des tests applicatifs. InboxTap peut injecter une erreur 451 ou une déconnexion pour déclencher ces parcours et montrer quelles tentatives SMTP ont abouti, mais ne possède pas le système de tâches.

Produire une preuve minimale et sûre

Préférez des éléments qui consignent le résultat de l’assertion, des participants pseudonymisés, la forme de l’URL et le résultat applicatif final sans conserver le secret réutilisable. Excluez la source RFC brute, sauf si un besoin précis de diagnostic l’emporte sur le risque de divulgation.

Les rapports InboxTap masquent les emplacements courants où apparaissent les jetons et les adresses, échappent le balisage capturé et restent bornés, mais le masquage demeure explicitement une protection au mieux. Ajoutez des motifs propres au projet et relisez le livrable avant de le partager.