Liste de contrôle des tests d'e-mails pour les développeurs : de la demande à l'expiration

Les tests d’e-mails font plus que confirmer qu’un message est apparu. Un test fiable suit l'événement depuis la demande de l'application jusqu'à la livraison, le rendu, l'action de l'utilisateur, l'expiration et le comportement des nouvelles tentatives. Il vérifie également que le flux échoue en toute sécurité.

Utilisez cette liste de contrôle uniquement sur les systèmes et les comptes que vous possédez ou que vous êtes autorisé à tester. N'utilisez pas de boîtes de réception temporaires pour créer des comptes groupés, contourner les limites d'un autre site Web ou tester un flux de réinitialisation tiers sans autorisation. Once Email reçoit uniquement des messages ; il n'envoie pas de réponses et ne peut pas prouver ce qui s'est passé dans l'application de l'expéditeur.

1. Définissez un scénario de test avant de demander un courrier

Enregistrez l'environnement, la build, le navigateur, la fonctionnalité et le résultat attendu avant d'appuyer sur le bouton. Donnez à chaque exécution un identifiant neutre tel que signup-valid-address ou reset-expired-link ; ne mettez pas de mot de passe, de jeton ou d’adresse personnelle dans le nom du test.

Préparez des cas pour les chemins réellement pris en charge par le produit :

• une demande d'inscription ou de vérification d'adresse valide ;
• une adresse avec une erreur de saisie évidente ;
• une demande répétée alors que le premier message est encore valide ;
• un code expiré ou déjà utilisé ;
• une demande de réinitialisation du mot de passe pour un compte existant et inexistant ;
• annulation, retour à la navigation et une deuxième session de navigation le cas échéant.

Le OWASP Web Security Testing Guide considère la réinitialisation comme une voie alternative vers un compte et recommande de revoir chaque interface prise en charge. Votre plan de test doit donc couvrir séparément l’interface web, l’application mobile et l’API lorsque leur comportement peut différer.

2. Vérifiez la réponse à la demande sans énumérer les utilisateurs

Soumettez une demande autorisée et notez la réponse visible, le statut et l’heure. Pour la récupération du mot de passe, les comptes existants et inexistants ne doivent pas divulguer l'appartenance au compte par des messages ou des délais de réponse clairement différents.

Ne générez pas un grand échantillon pour tester cela. Coordonnez les tests de charge, d'abus et de limite de débit avec le propriétaire du système, utilisez un environnement dédié et arrêtez-vous à la limite approuvée. L'aide-mémoire pour mot de passe oublié de l'OWASP (https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) recommande des réponses cohérentes et une protection contre les soumissions automatisées excessives, car un point de terminaison réinitialisé peut autrement exposer l'existence d'un compte ou inonder une boîte de réception.

Vérifiez qu'un deuxième clic ne crée pas silencieusement une collection dangereuse de secrets valides simultanément. La politique envisagée pourrait invalider le premier code, réutiliser une demande en attente ou autoriser un nombre soigneusement limité ; l'équipe produit doit définir quel résultat est correct.

3. Observez la livraison comme un état chronométré et non comme une assertion instantanée

Démarrez un minuteur lorsque l'application accepte la demande. Enregistrez le moment où le message devient visible, mais utilisez une fenêtre d'observation raisonnable au lieu de traiter quelques secondes de retard comme un échec. Le courrier passe par des files d’attente et des filtres, l’heure d’arrivée est donc une distribution plutôt qu’une constante fixe.

Lorsque vous utilisez Once Email pour un test autorisé à faible risque :

1. Créez ou sélectionnez une adresse de réception uniquement avec une durée de vie restante suffisante.
2. Copiez l'adresse exactement dans l'application testée.
3. Demandez un message et gardez la boîte de réception ouverte.
4. S'il n'apparaît pas, actualisez délibérément et suivez la liste de contrôle de dépannage par e-mail de vérification.
5. Enregistrez la demande et les heures d'arrivée observées en UTC, ainsi que l'environnement de test.

Ne prétendez pas qu’un message manquant prouve que l’expéditeur ne l’a jamais envoyé. Les journaux d'application, les événements du fournisseur et les en-têtes de message sont des sources de preuves distinctes. Utilisez une valeur de corrélation créée par le système de test lorsque cela est possible, mais ne l'exposez pas publiquement si elle accorde l'accès ou identifie un utilisateur.

4. Validez le message en tant que contenu et données

Comparez le sujet reçu, le domaine de l'expéditeur et l'objectif visible avec le modèle approuvé. Vérifiez les alternatives en texte brut et HTML lorsque l'application génère les deux. Vérifiez l'espacement, l'habillage, le contraste des couleurs et l'ordre significatif du contenu sur un ordinateur de bureau et dans une fenêtre d'affichage mobile étroite.

Vérifiez ensuite les données variables :

• l'adresse de test prévue apparaît là où elle est requise et nulle part de manière inattendue ;
• le nom de l'environnement est suffisamment clair pour éviter que le courrier intermédiaire ne soit confondu avec le courrier de production ;
• les dates et les déclarations d'expiration utilisent un fuseau horaire sans ambiguïté ;
• le code ou l'action est associé au bon scénario de test ;
• les liens utilisent HTTPS et l'hôte attendu ;
• aucune trace de pile interne, clé API, mot de passe ou données client non liées n'apparaît.

N'ouvrez pas un lien suspect simplement pour découvrir sa destination. Copiez le message HTML dans le navigateur local email link checker pour répertorier les URL et les ressources distantes sans afficher l'e-mail, puis comparez l'hôte de destination avec la spécification de test.

5. Succès, réutilisation et expiration de l'exercice

Pour un code ou un lien, testez une fois le chemin heureux approuvé. Confirmez qu'il effectue uniquement l'action prévue, atteint l'environnement correct et n'expose pas le secret dans un élément de page ou un événement d'analyse inutile.

Ensuite, vérifiez les transitions de sécurité :

• un secret à usage unique cesse de fonctionner après succès ;
• un secret expiré est rejeté sans terminer l'action ;
• une valeur mal formée échoue en toute sécurité ;
• une demande de remplacement suit la règle d'invalidation documentée ;
• l'ouverture de l'action dans un autre navigateur ne contourne pas le contexte requis ;
• une réinitialisation de mot de passe n'affaiblit pas automatiquement l'authentification multifacteur et ne laisse pas actives les sessions indésirables.

L'OWASP recommande des secrets de réinitialisation aléatoires, suffisamment longs, stockés en toute sécurité, à usage unique et expirant. Il recommande également la réinitialisation des URL HTTPS et des protections contre les devinettes. Votre test doit vérifier le comportement du produit et non tenter une force brute incontrôlée.

6. Testez les messages d'échec et la récupération

Un utilisateur a besoin d'une prochaine étape utile lorsque la livraison est retardée, qu'un code expire ou qu'un lien a déjà été utilisé. Confirmez que les erreurs ne révèlent pas l’existence du compte, des fragments secrets ou de l’infrastructure interne. L'interface doit permettre une nouvelle tentative légitime sans encourager des requêtes rapides et répétées.

Testez également ce qui se passe lorsque la boîte de réception temporaire expire avant que le flux de compte ne soit terminé. Une adresse jetable ne convient pas lorsque le compte nécessite une récupération à long terme, des reçus ou des avis de sécurité. Le guide de courrier électronique temporaire ou permanent explique quand une adresse permanente et contrôlée constitue l'hypothèse de test la plus sûre.

7. Enregistrez un résultat minimal et reproductible

Un résultat de test utile comprend le cas, l'environnement, la construction, la chronologie UTC, le résultat attendu, le résultat réel et un élément de preuve soigneusement rédigé. Indiquez si le problème concerne la création de la demande, la livraison du message, le contenu, l'action, l'expiration ou la récupération. Évitez un résultat vague tel que « e-mail cassé ».

Si la preuve contient une adresse, un code de vérification, un lien de réinitialisation, un ID de message, un cookie ou un nom d'hôte interne, ne la téléchargez pas telle quelle. Suivez le guide de rédaction des preuves de test par courrier électronique avant de le joindre à un problème.

Liste de contrôle pour la décision de publication

Avant de marquer le flux comme prêt, vérifiez que les cas de réussite autorisés réussissent, que les cas négatifs échouent en toute sécurité, que les règles de nouvelle tentative et d'expiration correspondent aux spécifications, que le contenu fonctionne sur une largeur étroite, qu'aucun secret n'entre dans les journaux ou les analyses et que les preuves peuvent reproduire les échecs sans exposer d'informations d'identification utilisables. Une arrivée réussie constitue une preuve utile, mais il ne s’agit pas d’un test complet du flux de courrier électronique.