Le spam dans les formulaires de contact, sans pistage

Un atelier de vélos à Neuchâtel a un formulaire de contact sur son site : nom, e-mail, message, c’est tout. Au début, il servait aux demandes de réparation et aux questions sur les vélos électriques. Aujourd’hui, ce sont une quarantaine de messages par semaine, dont trois authentiques. Les autres proposent du référencement, contiennent des liens vers des sites douteux ou ne sont qu’une suite de caractères.

Le webdesigner propose un CAPTCHA. Le patron hésite : il a lui-même déjà désespéré devant des images de feux et de passages piétons. Existe-t-il d’autres solutions ?

Il en existe plusieurs. Elles se distinguent par ce qu’elles font contre le spam, par ce qu’en remarquent les personnes qui remplissent le formulaire, et par les données en jeu.

D’où vient le spam

Le spam de formulaire est souvent envoyé non par des personnes, mais par des programmes qui parcourent les sites à la recherche de formulaires et les remplissent automatiquement. De là vient l’approche de presque toutes les protections : distinguer les programmes des personnes. C’est précisément pour cela que les CAPTCHA ont été inventés — et c’est précisément là que réside leur problème, comme le décrit le W3C.

Les solutions en un coup d’œil

Dans sa note sur l’inaccessibilité des CAPTCHA, le W3C cite plusieurs alternatives qui se passent de tâche visible. Avec les CAPTCHA eux-mêmes, on obtient le tableau suivant :

Solution	Comment elle fonctionne	Ce que remarque la personne
Pot de miel (honeypot)	Un champ caché que les personnes ne voient pas, mais que les programmes remplissent	Rien
Contrôle du temps	Les formulaires envoyés en une fraction de seconde sont repérés	Rien
Limitation du débit	Trop d’envois en peu de temps sont freinés	Rien, sauf en cas d’afflux
Filtre de contenu	Les motifs typiques du spam sont reconnus dans le texte	Rien, sauf en cas d’erreur
CAPTCHA avec tâche	Images, texte déformé ou audio à résoudre	Une tâche avant l’envoi
Service comportemental	Un service tiers évalue si la personne est humaine	En général rien, parfois une tâche

Aucune solution n’arrête tout le spam. Certaines entreprises combinent deux ou trois des solutions discrètes et se passent ainsi de tâche visible.

CAPTCHA et accessibilité

Le W3C relève qu’un CAPTCHA ne sépare pas seulement les ordinateurs des humains, mais empêche souvent aussi des personnes handicapées d’aller au bout d’une démarche. Les personnes aveugles ne peuvent pas lire un texte déformé, les personnes sourdes peinent avec la version audio, et pour les personnes ayant des troubles cognitifs, les échecs répétés peuvent être très pénibles.

Les WCAG exigent en principe un équivalent textuel pour les contenus non textuels ; pour les CAPTCHA, elles prévoient une exception, mais demandent alors une description du but et des formes alternatives adaptées à différents sens (critère 1.1.1). Pour un petit formulaire de contact, la question est donc de savoir si l’obstacle est proportionné à son utilité.

Ce que traitent les services tiers

Les services comportementaux sont pratiques : ils fonctionnent en arrière-plan et ne demandent en général aucune tâche. En contrepartie, ils analysent des données du navigateur de la visiteuse. Pour ces services, le W3C décrit notamment l’analyse des cookies et des interactions sur la page, et exprime des réserves en matière de protection des données. Dans ses réponses sur reCAPTCHA, Google indique que le service dépose un cookie nécessaire à son analyse de risque, et exige que la mention de reCAPTCHA reste visible dans le parcours.

Pour l’entreprise, un tel service signifie que des données personnelles des visiteuses partent chez un tiers, le cas échéant à l’étranger. Qui collecte des données personnelles informe les personnes concernées notamment des destinataires et, en cas de communication à l’étranger, de l’État concerné (art. 19, al. 2 et 4, LPD). Un tel service a donc sa place dans la déclaration de protection des données.

Pot de miel et contrôle du temps

Les deux solutions les plus simples tournent sur son propre serveur et n’ont besoin d’aucun tiers.

Le pot de miel est un champ supplémentaire invisible pour les personnes. Un programme qui remplit tous les champs remplit aussi celui-ci — et l’envoi est rejeté. Le W3C cite expressément les pots de miel comme alternative. Deux points demandent du soin : le champ doit aussi être masqué pour les lecteurs d’écran, sinon une personne aveugle entend un champ qu’elle ne doit pas remplir. Et le remplissage automatique du navigateur ne devrait pas le cibler.

Le contrôle du temps mesure le délai entre le chargement de la page et l’envoi. Une personne a besoin d’au moins quelques secondes pour un nom, une adresse e-mail et un message ; un programme, souvent d’une fraction de ce temps. Une limite trop stricte touche toutefois les personnes qui remplissent vite grâce à des données enregistrées.

Limitation du débit et filtres

Une limitation du débit freine lorsque de nombreux envois proviennent de la même source en peu de temps. Le W3C cite aussi cette méthode. Elle suppose que le serveur reconnaisse une source, en général par son adresse IP. Pour la minimisation des données, cela signifie : ne la conserver que le temps nécessaire au frein, soit des minutes ou des heures, pas des mois.

Un filtre de contenu examine le texte, par exemple la présence de nombreux liens ou de formulations typiques. Le W3C mentionne les filtres anti-spam comme autre possibilité. Le risque tient ici aux erreurs : une vraie demande contenant deux liens vers des pièces de vélo peut rester bloquée dans le filtre.

Ce qui reste après le filtre

Chaque solution se trompe dans les deux sens : un peu de spam passe, et de temps en temps une vraie demande atterrit dans le mauvais dossier. Il est donc utile d’avoir un endroit où les messages écartés restent un moment et peuvent être parcourus avant d’être supprimés. Et pour les personnes qui remplissent le formulaire : une alternative, comme un numéro de téléphone ou une adresse e-mail, au cas où l’envoi ne fonctionnerait pas.

Quand le formulaire envoie lui-même des messages

Une particularité de certains formulaires de contact attire particulièrement le spam : l’option « M’envoyer une copie ». Le formulaire envoie alors un e-mail à l’adresse saisie dans le champ — et cette adresse peut être n’importe laquelle. Un programme peut ainsi utiliser le formulaire de l’atelier pour envoyer des messages à des inconnus, avec l’atelier comme expéditeur. Renoncer à cette option, ou n’envoyer la copie qu’après une confirmation, ôte sa base à ce type d’abus.

Et pour les messages qui passent malgré tout : les liens contenus dans le spam mènent souvent à des pages qui cherchent à capter des identifiants ; ne pas cliquer dessus évite ce risque.

Pour l’atelier de Neuchâtel

L’atelier renonce au CAPTCHA. Son formulaire reçoit un pot de miel masqué aussi pour les aides techniques, et un contrôle du temps de quelques secondes. Les messages retenus arrivent dans un dossier séparé que le patron parcourt le vendredi. Sous le formulaire figurent le numéro de téléphone et les heures d’ouverture. Les prochaines semaines diront si cela suffit ; une limitation du débit pourrait s’ajouter plus tard.

Dans l’app Formulaires que nous développons, les réponses sont chiffrées dans le navigateur de la personne qui répond et ne redeviennent lisibles que chez la destinataire. Pour la protection contre le spam, nous suivons le même principe que cet article : se contenter des données dont un formulaire a besoin de toute façon.