Qui d’autre lit par-dessus l’épaule ? Les scripts tiers sur les pages de formulaire

Lorsque quelqu’un remplit votre formulaire de contact, il suppose que le message vous parvient. Sur de nombreux sites, pourtant, la page du formulaire exécute aussi des scripts de fournisseurs d’analyse, de régies publicitaires, d’éditeurs de chat et de tout ce qu’un gestionnaire de balises a accumulé au fil des années. Chacun de ces scripts s’exécute avec les mêmes droits que votre propre code : il peut lire la page, observer les champs de saisie et envoyer des données vers ses propres serveurs. Cela ne veut pas dire qu’ils le font tous. Mais sur la page où les visiteurs saisissent leur nom, leur adresse e-mail et parfois des informations sur leur santé, leurs finances ou leurs difficultés juridiques, vous devriez savoir qui lit par-dessus leur épaule.

Les suspects habituels

• Les outils d’enregistrement de session enregistrent les clics, le défilement et souvent les frappes au clavier afin qu’une visite puisse être rejouée ultérieurement. Si les champs ne sont pas masqués, cela peut inclure ce que les personnes tapent dans le formulaire.
• Les pixels publicitaires et d’analyse signalent les pages vues et les conversions à des tiers – sur la page du formulaire elle-même et très souvent sur la page de remerciement.
• Les widgets de chat chargent une application complète depuis un autre domaine, généralement sur chaque page, y compris celle du formulaire.
• Les gestionnaires de balises permettent au marketing d’ajouter des scripts sans déploiement. C’est pratique, mais cela signifie aussi que du code peut atteindre la page du formulaire sans que personne ne l’ait examiné.
• Les petits outils annexes – tests A/B, cartes de chaleur, contenus sociaux intégrés, polices, cartes – ajoutent chacun un hôte qui reçoit au moins l’adresse IP du visiteur et généralement l’adresse de votre site ; les scripts parmi eux peuvent aussi lire l’URL complète de la page.

Enregistrement de session : un enregistreur à côté du champ de saisie

La plupart des outils d’enregistrement proposent des réglages pour masquer les champs de saisie ou exclure des zones entières, et certains masquent certains champs par défaut. Les points faibles sont les exceptions : un champ de message libre que le réglage par défaut ne couvre pas, un formulaire construit à partir de composants que les règles de masquage ne reconnaissent pas, ou un réglage que quelqu’un a désactivé pendant un débogage et n’a jamais réactivé. Un enregistrement stocké chez un tiers peut alors contenir exactement ce que le visiteur vous a écrit – ce à quoi il ne s’attendait pas et que votre politique de confidentialité, qui, en vertu de l’Art. 13 RGPD, doit mentionner les destinataires ou catégories de destinataires des données à caractère personnel, ne mentionne peut-être pas du tout.

Les pixels et la page de remerciement

Le suivi des conversions a besoin d’un signal indiquant qu’un formulaire a été envoyé, et la page de remerciement est l’endroit évident pour le déclencher. La plupart des pixels envoient l’adresse complète de la page avec chaque événement. Si le formulaire envoie ses données via GET, ou si la redirection après l’envoi ajoute à l’URL des valeurs comme ?name=…&email=…, ces valeurs partent directement chez le fournisseur publicitaire ou d’analyse. Certains pixels proposent en outre des fonctions qui récupèrent automatiquement les adresses e-mail ou les numéros de téléphone dans les formulaires afin d’améliorer la correspondance. Et si le pixel se déclenche avant que le visiteur ait répondu à la bannière de cookies – ou après qu’il a refusé –, le problème n’est plus seulement technique.

Gestionnaires de balises, consentement et chaîne d’approvisionnement

C’est souvent dans les gestionnaires de balises que la vue d’ensemble se perd. Une balise de campagne pour un salon d’il y a deux ans, l’essai d’un outil de carte de chaleur, un pixel pour un réseau que plus personne n’utilise – tout cela peut encore se charger sur chaque page, y compris celle du formulaire. Les déclencheurs sont fréquemment réglés sur « toutes les pages », et les règles de consentement sont configurées balise par balise ; une seule balise à laquelle manque une condition suffit donc à charger un script avant que le visiteur ait donné son accord.

Vient ensuite la chaîne d’approvisionnement. Lorsque vous intégrez un script provenant d’un autre hôte, vous faites confiance à celui qui contrôle cet hôte aujourd’hui et à l’avenir. Un éditeur peut modifier ce que fait son script, être racheté ou voir son infrastructure de diffusion compromise. Le navigateur ne peut pas distinguer un script légitime d’un script manipulé ; du code injecté sur une page de formulaire peut donc lire chaque champ et l’envoyer n’importe où – le même schéma que celui utilisé pour le skimming sur les pages de paiement.

Ce que vous pouvez faire

1. 1Faites l’inventaire. Ouvrez chaque page de formulaire et sa page de remerciement avec les outils de développement du navigateur, consultez l’onglet Réseau et listez chaque hôte externe. Faites-le une fois sans consentement et une fois après avoir accepté la bannière.
2. 2Supprimez ce dont personne n’a besoin. Les balises sans responsable ni finalité clairs sont candidates à la suppression. Limitez les déclencheurs du gestionnaire de balises afin que seules les balises qui doivent s’exécuter sur les pages de formulaire le fassent.
3. 3Masquez les saisies dans les outils d’enregistrement. Masquez tous les champs de saisie, pas seulement les mots de passe, et excluez entièrement la zone du formulaire si possible. Regardez ensuite un enregistrement pour voir ce qui a réellement été stocké.
4. 4Envoyez les conversions sans données à caractère personnel. Envoyez les données du formulaire via POST, tenez les valeurs du formulaire hors des URL de redirection et déclenchez un événement neutre comme « contact_form_sent ». Désactivez la collecte automatique des champs de formulaire dans les pixels.
5. 5Ne chargez qu’après consentement. Les scripts qui nécessitent un consentement ne doivent pas se charger avant que le visiteur ait donné son accord – et doivent rester désactivés s’il refuse. Testez les deux parcours.
6. 6Figez et restreignez lorsque c’est possible. Subresource Integrity (une empreinte sur la balise script) amène le navigateur à refuser un fichier statique qui a été modifié ; cela ne convient pas aux scripts qui changent par nature, comme les gestionnaires de balises. Une Content Security Policy limite les hôtes autorisés à exécuter des scripts – commencez en mode report-only pour voir ce qui serait cassé.
7. 7Surveillez les changements. Un nouvel hôte de script sur une page de formulaire devrait être une décision délibérée, pas une surprise. Assurez-vous d’être averti lorsqu’il en apparaît un.

formexposed vérifie quels pixels de suivi se déclenchent sur vos pages de formulaire, si un outil d’enregistrement de session est susceptible d’enregistrer les saisies du formulaire et si le refus de la bannière de cookies arrête réellement le pistage – de manière passive, rien n’est soumis. Une vérification gratuite indique le niveau global ; ces constats figurent dans le rapport complet. Avec la surveillance d’un domaine vérifié, formexposed vous alerte également lorsqu’un nouvel hôte de script apparaît sur une page de formulaire.