Trois cent quarante soumissions par jour sur un formulaire de contact qui, en temps normal, en recevait une dizaine : c’est le volume atteint en une semaine sur le site d’un centre hospitalier universitaire, avant que l’équipe technique ne s’en aperçoive via une alerte de son fournisseur d’hébergement mutualisé, saturé par les envois d’e-mails de notification.
Le formulaire disposait pourtant d’un honeypot classique : un champ caché nommé website, invisible en CSS mais présent dans le HTML, censé piéger les robots qui remplissent tous les champs d’un formulaire sans distinction. Ce mécanisme, longtemps suffisant, avait cessé de fonctionner.
Symptôme : un honeypot qui ne piège plus rien
L’analyse des soumissions bloquées côté serveur montrait que le champ honeypot arrivait systématiquement vide, exactement comme pour un envoi légitime. Pourtant, le contenu des messages ne laissait aucun doute : liens vers des sites de contrefaçon, formulations répétées à quelques variations près, adresses e-mail jetables générées en masse. Le spam passait bien par le formulaire, mais sans jamais déclencher le piège censé l’arrêter.
Un examen du code source de la page a permis de comprendre pourquoi : le champ honeypot portait l’attribut name="website" et un simple display: none en CSS inline, un motif suffisamment répandu et documenté pour que des scripts de spam génériques le reconnaissent et évitent délibérément de le remplir.
Diagnostic : un indicateur unique, donc contournable
Le problème de fond n’était pas le principe du honeypot, mais sa solitude : un seul indicateur, statique et documenté publiquement dans de nombreux tutoriels, devient un motif reconnaissable par n’importe quel script un tant soit peu à jour. Dès qu’un signal de détection repose sur un nom de champ ou une classe CSS prévisible, sa durée de vie utile se compte en mois, pas en années.
Le contexte aggravait la situation : un établissement de santé publie souvent son formulaire de contact sur une URL stable, indexée et documentée, ce qui en fait une cible plus attractive pour des campagnes de spam automatisées à grande échelle que pour un site vitrine anonyme.
Correctif : combiner plusieurs signaux indépendants
La correction a consisté à superposer trois vérifications indépendantes plutôt que de renforcer le honeypot seul :
- Un délai de soumission minimal : un formulaire rempli en moins de trois secondes après son affichage est presque toujours automatisé, un humain ayant besoin de temps pour lire les champs et taper son message.
- Un nonce à courte durée de vie via
wp_create_nonce(), renouvelé à chaque affichage du formulaire, qui invalide les scripts qui rejouent une soumission enregistrée une fois pour toutes. - Un second honeypot renommé dynamiquement, dont le nom de champ change à chaque chargement de page via un jeton côté serveur, rendant impossible tout ciblage générique par nom de champ.
$elapsed = time() - (int) $_POST['form_rendered_at'];
if ($elapsed < 3) {
wp_die('Soumission trop rapide.');
}
if (!empty($_POST[$honeypot_field_name])) {
wp_die('Requête rejetée.');
}
if (!wp_verify_nonce($_POST['_wpnonce'], 'contact_form_submit')) {
wp_die('Session expirée, merci de recharger la page.');
}Prévention : ne jamais dépendre d’un seul signal
Depuis ce correctif, le volume de spam est retombé sous la dizaine de tentatives par semaine, toutes bloquées par la combinaison des trois vérifications. Le principe retenu pour les projets suivants est simple : aucun mécanisme anti-spam ne repose sur un unique indicateur statique, qu’il s’agisse d’un honeypot, d’un champ caché ou d’une simple vérification de referer, car chacun de ces signaux, pris isolément, finit par être documenté et contourné.
Un bon anti-spam ne cherche pas un signal parfait : il additionne plusieurs signaux imparfaits, difficiles à simuler tous en même temps par un script générique.
Notre verdict
Pour un établissement public exposé à un volume de trafic important et à une audience large, un simple honeypot ne suffit plus depuis longtemps. La combinaison délai, nonce et honeypot dynamique reste légère à mettre en œuvre, ne dégrade pas l’expérience des visiteurs légitimes, et résiste nettement mieux aux campagnes automatisées actuelles que n’importe lequel de ces mécanismes pris seul.
