Un échec du lien magique peut se produire une fois la livraison du courrier réussie. Le message peut arriver après l'expiration, l'application peut invalider un lien antérieur ou une redirection peut atterrir sur le mauvais environnement. Examinez-les comme des hypothèses distinctes plutôt que de traiter chaque échec de connexion comme un problème d’enregistrement d’authentification.
Retracez les deux voyages
Le parcours du courrier s'étend de la demande à la génération, en passant par la mise en file d'attente et l'acceptation du serveur de réception. Le parcours de l'application s'étend de la création du jeton à la demande de lien, en passant par la validation et l'établissement de la session. Rejoignez-les en utilisant un identifiant de corrélation non secret. N'enregistrez pas de liens porteurs complets et ne collez pas de lien actif dans un scanner externe.
Un événement d'acceptation SMTP constitue une preuve de la responsabilité du transfert, et non une session utilisateur terminée. Gardez les étiquettes de support précises. RFC 5321. Enregistrez explicitement la visibilité manquante lorsque le fournisseur expose uniquement la soumission et le statut final.
Conseils de journalisation OWASP prend en charge la corrélation sans exposer les secrets d'accès.
Valider la conception du lien séparément
Les principes de sécurité des directives de réinitialisation de mot de passe de l'OWASP incluent les jetons à usage unique expirant, les destinations HTTPS fiables et la protection contre les fuites de jetons. Ces principes sont pertinents pour l'examen des liens sensibles envoyés par courrier électronique, mais la source concerne la réinitialisation du mot de passe plutôt que une spécification complète pour la connexion sans mot de passe. Un produit Magic-Link a besoin de son propre modèle de menace et de ses propres contrôles de session. Conseils de réinitialisation du jeton OWASP.
Inspectez le comportement prévu de l'hôte, de l'environnement, du chemin et de la redirection à l'aide d'informations d'identification de test jetables dans un environnement de test approuvé. Confirmez si une demande plus récente invalide les liens précédents et si une utilisation réussie invalide le jeton. Enregistrez la politique réelle au lieu de supposer que tous les produits se comportent de manière identique.
Comparez un échec d’expiration et un échec de consommation
Considérons deux jetons hypothétiques créés à 09h00 UTC et expirant à 09h10. Le cas A atteint l'acceptation du récepteur à 09h11, déjà une minute après l'expiration. Le cas B atteint ce stade à 09h01, a une demande de rachat réussie enregistrée à 09h02 et reçoit une deuxième tentative à 09h03. Dans le cadre d'une politique à usage unique, la deuxième tentative de B devrait échouer car elle a déjà été utilisée, même s'il reste sept minutes.
Il s’agit d’hypothèses d’événements inventées, et non d’exécutions de machines à états ou d’incidents vérifiés. Le cas A suggère une enquête temporelle ; le cas B nécessite des preuves de la transition de candidature antérieure. Un délai de courrier plus court ne rendrait pas B réutilisable. N'attribuez pas l'action précoce à un scanner de sécurité ou à une personne uniquement à partir d'une chaîne d'agent utilisateur. Corrélez les enregistrements de demandes expurgées autorisées, les changements d’état et les événements de session avant d’attribuer l’acteur.
Réparer sans rendre les liens réutilisables
Pour un véritable retard, résolvez la phase lente et vérifiez le budget de validité restant. En cas de consommation prématurée, vérifiez si l'application peut séparer une demande d'atterrissage inoffensive de l'action explicite et validée de manière sécurisée qui établit une session. Il s'agit d'une révision de conception, pas d'un correctif universel ; préserver la prévention des rediffusions, l’expiration et autres contrôles requis.
Supprimez le suivi marketing inutile des liens de compte sensibles via la configuration du modèle approuvé et vérifiez le message final. Tout comportement de redirection ou de lien profond mobile doit encore être testé. Ne résolvez jamais une panne intermittente en acceptant indéfiniment des jetons expirés.
Testez à nouveau les trajets contrôlés pour les arrivées retardées, les demandes répétées, les rediffusions et les itinéraires dans un mauvais environnement. Terminez avec la classe de défaillance exacte et les lacunes restantes. Une classification claire empêche les opérateurs de courrier et les ingénieurs d'application de modifier à plusieurs reprises le mauvais système.
Exiger une fermeture distincte pour chaque classe de défaillance
Une arrivée plus rapide ne peut clôturer un dossier de retard d'expiration qu'après qu'un voyage contrôlé ait confirmé la validité du budget. Il ne peut pas clôturer un dossier de consommation antérieure ou de mauvais environnement. Enregistrez le cours, soutenant la transition de l'application et les preuves manquantes avant d'attribuer une cause.