Votre lien de vérification est à usage unique. Cela ne prouve pas qui l’a ouvert.

Une vérification terminée appartient au client et au parcours créés par votre serveur. Avant de modifier les droits d’un compte, confrontez cette relation au résultat faisant autorité. Un retour navigateur réussi ou la possession d’un lien à usage unique ne suffit pas.

Prenons un exemple : un agent d’assistance copie une URL de vérification dans la mauvaise conversation. Même utilisable une seule fois, cette URL exige que vous sachiez quel compte les preuves obtenues peuvent affecter.

Créez le rattachement avant l’envoi

Créez le parcours depuis votre serveur avec la référence du client attendu, l’organisation, l’environnement et le workflow. Enregistrez la référence de session retournée dans cette demande avant de transmettre l’URL.

Ne laissez pas un identifiant client fourni par le navigateur déterminer quel compte devient vérifié. Contrôlez que le demandeur a le droit de lancer ce parcours pour ce compte.

Les recommandations OWASP sur l’autorisation (s’ouvre dans un nouvel onglet) préconisent de vérifier les droits à chaque requête. Appliquez ce principe à la création du parcours comme à l’utilisation du résultat.

Intégrez la diffusion au contrôle

Envoyez le lien par le canal destiné au client. Évitez les URL complètes de vérification dans les événements analytiques, captures et notes d’assistance qui n’en ont pas besoin. Transmettez des références plutôt que l’URL entre équipes.

Si le lien parvient à la mauvaise personne, utilisez les mécanismes documentés de révocation ou d’expiration du fournisseur lorsqu’ils existent. Ne supposez pas qu’un nouveau lien désactive l’ancien. Faites remonter le cas si l’exposition restante est incertaine.

Le guide OWASP sur les sessions (s’ouvre dans un nouvel onglet) explique les précautions liées aux jetons dans les URL. Confirmez le comportement réel du fournisseur au lieu d’inventer des garanties.

Acceptez le résultat sur votre serveur

À réception, vérifiez son authenticité et récupérez l’état actuel si nécessaire. Faites correspondre le résultat au client, au parcours et à l’environnement enregistrés. Vérifiez la décision finale exigée par votre politique avant d’accorder des droits.

L’écran de fin de capture peut annoncer la prochaine étape. Il ne doit pas approuver indépendamment le compte. Préservez le sens des états en attente, examiné et terminé.

Testez le mauvais destinataire

Testez deux clients dans des sessions navigateur distinctes, un lien ouvert par une autre personne, un parcours expiré et un résultat retardé. Confirmez qu’aucun résultat ne peut modifier un compte sans rapport.

Toden propose des parcours hébergés rattachés au client ; votre application applique toujours les droits du compte. Commencez par le guide lien hébergé ou SDK, puis utilisez les références d’intégration pour vérifier le rattachement de bout en bout.