Comment vérifier les requêtes du fournisseur de l’API Chrome Email Verification en 2026 ?

Point d’émission : des preuves à ne pas confondre

Le travail porte sur le service qui reçoit une requête de navigateur et peut émettre un jeton lié à une adresse. Il ne s’agit pas d’implémenter le côté site web qui reçoit et vérifie ensuite le jeton EVT. Ces deux rôles se situent à des endroits différents du parcours : le fournisseur traite la demande d’émission ; le site vérificateur consomme le résultat selon le flux décrit dans la documentation Chrome sur le fonctionnement de l’API.

Pour un Chrome Email Verification API issuer, une requête arrivée au serveur ne constitue donc pas une preuve de confiance. La présence de champs de signature ne prouve pas davantage qu’ils sont valides. Enfin, une signature valide ne démontre ni que la session correspond à l’utilisateur attendu ni que l’adresse demandée lui appartient.

Le point d’émission doit séparer les résultats, au minimum, dans ses journaux et ses réponses de traitement :

• Requête reçue : le serveur a reçu une demande. Elle peut encore être mal formée ou provenir d’un contexte inadmissible.
• Requête authentifiée et autorisée : la signature et le résumé ont été vérifiés, puis la session et l’adresse ont passé les contrôles métier.
• Jeton émis : le service a produit un résultat conforme au format en vigueur. Cela ne prouve pas que le navigateur l’a accepté.
• Vérification terminée : le site qui consomme le jeton a mené son propre contrôle à terme. Ce résultat ne se déduit pas de la seule réponse du fournisseur.

La documentation officielle décrit encore la fonctionnalité comme une Origin Trial à la date de mise à jour de cet article. Il faut donc considérer le guide d’émission et ses mises à jour comme la référence d’implémentation, plutôt que figer le comportement d’un essai à partir d’un ancien exemple.

Compatibilité du point d’émission selon les versions

Les formats évoluent : un serveur ne doit pas supposer que tous les navigateurs envoient les mêmes champs. Selon le guide officiel, à partir de Chrome 153, la requête d’émission utilise un corps JSON et HTTP Message Signatures. La documentation distingue ce format des requêtes précédentes ; les détails doivent être confirmés dans le guide correspondant, plutôt que déduits d’un seul exemple observé. Les notes d’août 2026 détaillent cette évolution.

Une autre transition concerne Sec-Fetch-Dest. À partir de Chrome 154, sa valeur est email-verification ; les versions antérieures peuvent utiliser l’écriture sans trait d’union, emailverification. L’implémentation doit reconnaître les formes documentées pour les versions prises en charge, sans traiter cet en-tête comme une authentification. Les notes d’octobre 2026 documentent également des changements à partir de Chrome 156, notamment concernant l’identifiant d’algorithme de signature et le traitement de la déclaration d’adresse.

Une transition n’implique pas que chaque client adopte immédiatement la même forme. Lors des essais, associez donc le résultat au navigateur réellement utilisé et au format réellement reçu. Une règle de compatibilité peut accepter des variantes officiellement documentées ; elle ne doit pas tolérer un en-tête arbitraire ou une signature manquante.

Le changement de Sec-Fetch-Dest après Chrome 154 affecte-t-il le fournisseur ?

Oui, dans la mesure où un fournisseur peut recevoir des requêtes issues de versions différentes. Il doit connaître les valeurs documentées et éviter de rejeter une requête légitime uniquement parce qu’elle utilise la forme antérieure. Mais cette valeur ne valide ni l’origine cryptographique de la demande ni l’identité du compte. Elle sert de donnée de contexte, pas de substitut à la vérification de signature.

Une stratégie d’exploitation raisonnable consiste à enregistrer la valeur reçue, à appliquer les contrôles cryptographiques indépendamment, puis à suivre la proportion des formats observés dans les environnements autorisés. Si l’équipe ne prend plus en charge une variante, la décision doit être documentée et testée ; elle ne doit pas être introduite silencieusement par une mise à jour de dépendance ou de configuration.

Développeurs du point d’émission : vérification de la signature HTTP

Pour vérifier la signature, la question n’est pas « les en-têtes sont-ils présents ? », mais « les éléments signés correspondent-ils à cette requête, à la clé attendue et au contexte de réception ? ». Les champs Signature, Signature-Input, Signature-Key et Content-Digest ont des responsabilités distinctes dans le traitement décrit par le guide officiel. Les implémentations doivent suivre les exemples actuels du fournisseur et le mécanisme défini par RFC 9421 sur les signatures de messages HTTP.

La procédure opérationnelle peut être organisée ainsi :

• Lire le message sans en altérer la représentation utile. Définissez à quel moment le corps est lu et comment il est transmis au vérificateur. Un composant qui consomme le corps avant le contrôle du résumé peut créer des divergences entre ce qui a été vérifié et ce qui est traité.
• Valider les champs requis. Refusez une signature absente, une entrée de signature impossible à analyser ou une clé qui ne correspond pas à la politique attendue. La simple présence de Signature ou Signature-Input ne prouve pas leur validité.
• Vérifier les composants couverts. Confirmez que la vérification porte sur les composants requis pour la requête reçue, et pas uniquement sur une partie choisie par l’application. L’équipe doit comparer sa mise en œuvre aux composants indiqués dans le guide et aux règles de signature de RFC 9421.
• Vérifier le résumé du corps. Recalculez le résumé des octets reçus et comparez-le à Content-Digest avant d’utiliser le JSON pour décider d’émettre. Une signature acceptée ne rend pas correct un corps dont le résumé ne correspond pas.
• N’émettre qu’après les contrôles d’autorisation. Une vérification cryptographique réussie est nécessaire, mais elle ne dispense pas de valider la session et l’adresse.

Les mandataires inverses et répartiteurs de charge méritent une vérification distincte. Le serveur applicatif peut voir un nom d’hôte interne alors que la requête publique était adressée à une autre autorité. Si les composants signés incluent des données liées à l’autorité, reconstruire celles-ci à partir du seul nom interne peut faire échouer une signature légitime ou, pire, conduire l’application à vérifier une représentation différente de celle reçue.

Documentez la source de chaque valeur publique transmise par le mandataire, les en-têtes qu’il est autorisé à définir et les règles de confiance appliquées à ce mandataire. Ne faites pas confiance à un Host ou à un en-tête de transfert fourni directement par un client non fiable. La terminaison TLS protège le transport sur un segment donné ; elle ne remplace pas la vérification de signature du message.

Contrôle de décision entre variantes et niveaux de preuve

Le tableau suivant aide à choisir quoi faire d’une requête dans les essais comme en production. Il sépare la compatibilité de format des conditions de confiance : reconnaître une version n’autorise jamais à ignorer un contrôle cryptographique.

Ne fusionnez pas les états « signature rejetée » et « session non valide ». Le premier indique un échec d’authenticité ou d’intégrité de la requête ; le second concerne l’autorisation de l’utilisateur. Cette distinction accélère l’analyse d’un incident et empêche qu’un tableau de bord donne l’impression que toutes les requêtes refusées relèvent d’un même problème de navigateur.

Responsables des comptes : session et adresse cible

Avant l’émission, rattachez la demande à une session valide selon les règles du service. Vérifiez que cette session représente bien l’utilisateur autorisé à demander la vérification et qu’elle n’a pas expiré ou été invalidée. Une requête correctement signée ne suffit pas si elle ne peut pas être associée à la session attendue.

Comparez ensuite l’adresse demandée avec l’adresse que le compte est autorisé à faire vérifier. Une normalisation interne peut être utile pour rechercher une identité ou comparer des valeurs selon la politique du service. Il faut néanmoins distinguer cette valeur de travail de la chaîne d’adresse que le jeton doit reprendre. Le guide officiel précise qu’à partir de Chrome 156, la déclaration d’adresse du jeton doit correspondre à la valeur de la requête ; l’équipe doit donc éviter de normaliser la valeur retournée d’une façon qui la ferait diverger de la demande.

Cette différence mérite des essais explicites : même compte et même adresse ; session valide mais autre adresse ; session invalide avec adresse connue ; représentation normalisée qui semble équivalente mais ne doit pas remplacer la valeur de requête dans le jeton. Les règles d’équivalence doivent venir de la politique documentée du service, et non d’hypothèses générales sur les fournisseurs de boîtes aux lettres.

Les données d’essai doivent être isolées des comptes réels. Utilisez des sessions et des adresses réservées aux tests, limitez les journaux aux éléments nécessaires au diagnostic et empêchez les environnements de préproduction d’émettre des jetons utilisables en production. Pour cadrer les risques de données personnelles dans ces scénarios, les équipes peuvent consulter les principes de protection de la vie privée applicables à leurs propres processus de test.

Sécurité et QA : refus, émission et retour au courriel

Un essai positif seul ne valide pas le point d’émission. Il démontre au mieux qu’un chemin favorable fonctionne. La campagne de validation doit aussi chercher à prouver que les demandes mal formées ou non autorisées n’aboutissent pas à l’émission d’un jeton.

Préparez des cas séparés pour une signature valide, une signature absente, une signature incorrecte, un résumé qui ne correspond pas au corps, une session non valable et une adresse différente de celle associée au compte. Pour chaque cas négatif, vérifiez deux résultats : la demande est refusée au stade attendu et aucun chemin secondaire ne déclenche malgré tout l’émission. Il faut notamment inspecter les reprises, les files de traitement et les gestionnaires d’erreur, où un contrôle oublié peut contourner le refus initial.

La confirmation par courriel est un parcours de repli fonctionnel, pas une preuve que l’API a réussi. Elle doit rester disponible lorsque le navigateur ne prend pas en charge le mécanisme, qu’aucun jeton n’est obtenu ou que le site consommateur ne valide pas le résultat. Cette séparation répond à l’intention de test de repli par courriel : la solution de secours confirme l’adresse par son propre flux, sans prétendre réparer une signature invalide ni transformer un échec de l’API en réussite.

Pour organiser les essais, l’équipe QA peut suivre ce déroulé :

• Configurer un environnement isolé avec des comptes, des clés et des sessions dédiés.
• Exécuter les cas positifs et négatifs en enregistrant le format réellement reçu.
• Comparer le résultat de vérification avec les traces du service, sans consigner de secret privé.
• Vérifier qu’aucun jeton n’est émis pour une signature invalide, un résumé incohérent ou une adresse non autorisée.
• Tester séparément le navigateur, le fournisseur et le site vérificateur, afin de ne pas attribuer au fournisseur une preuve qui appartient au site consommateur.
• Déclencher les scénarios où le mécanisme est indisponible, puis confirmer que le parcours de courriel déjà en place reste utilisable.
• Consigner la version de Chrome, la forme de la requête, la décision du fournisseur et la preuve du repli.

Dans les environnements où le courriel de secours est testé de bout en bout, il est utile de vérifier la réception réelle du message plutôt que de s’arrêter à la réponse du serveur d’envoi. Un outil de contrôle de réception peut servir à examiner cette partie du parcours ; la réception d’un message de test ne garantit toutefois ni sa livraison en production ni la réussite de la vérification Chrome.

Le dossier de mise en production doit ainsi distinguer quatre résultats : demande reçue, signature et intégrité validées, jeton émis, puis vérification achevée côté site. Ajoutez-y la compatibilité avec les formats officiellement pris en charge et les preuves du parcours de repli. Cette traçabilité évite de transformer un seul code de réponse en affirmation de réussite sur toute la chaîne.

Pour tester uniquement la réception d’un message de confirmation de votre propre produit, une boîte temporaire peut compléter les comptes de test sans exposer une adresse professionnelle ni encombrer sa boîte principale. ZOSend peut être envisagé pour ce besoin de collecte ponctuelle ; il ne remplace ni le point d’émission Chrome, ni le contrôle de signature, ni un compte durable nécessaire à la récupération.