Honeypot de formulaire WordPress : arrêter les robots sans captcha
Un honeypot de formulaire arrête les robots de spam dans WordPress avec un champ que les personnes ne voient jamais et que les robots remplissent toujours, et ReportedIP Hive le combine avec une preuve que le formulaire a réellement été affiché dans un navigateur. Ce guide explique les deux couches, ce qu’il advient d’un envoi refusé et quels formulaires sont protégés dans quelle formule, sans le moindre captcha.
Qu’est-ce qu’un honeypot de formulaire ?
Un honeypot est un champ de formulaire supplémentaire, caché aux personnes. Il est placé hors de l’écran, ignoré par la navigation au clavier et par le remplissage automatique, et masqué aux lecteurs d’écran. Une personne n’y touche jamais. Un robot de spam qui remplit chaque champ qu’il trouve remplit aussi celui-ci, et cela suffit pour savoir que l’envoi ne vient pas d’une personne.
L’avantage sur un captcha : personne n’a rien à résoudre. Pas d’image déformée, pas de puzzle de feux de circulation, pas de script tiers qui suit les visiteurs. La limite est tout aussi claire : un robot écrit pour un site précis peut apprendre à laisser le champ vide. C’est pourquoi Hive ne s’appuie pas sur le honeypot seul. L’interface de Hive est en anglais, les libellés et messages cités dans ce guide restent donc en anglais.
Pourquoi un honeypot seul ne suffit pas
Beaucoup de scripts de spam ne chargent jamais le formulaire. Ils envoient leurs données directement à l’adresse qui traite les commentaires ou les inscriptions, par exemple wp-comments-post.php. Un tel script ne voit jamais le honeypot, ne peut donc pas le remplir, et passe une vérification qui se contente de chercher un champ rempli.
Hive ajoute donc la Form execution proof. Le serveur place un champ d’ancrage caché dans le formulaire, et un petit script dans le navigateur ajoute un second champ dont le nom diffère sur chaque installation. Un script qui envoie directement à l’adresse n’a jamais exécuté ce code, le second champ manque donc. La page reste identique pour chaque visiteur, ce qui permet aux caches de pages de continuer à fonctionner.
Les quatre verdicts pour chaque envoi
À partir des deux champs, Hive rend l’un de quatre verdicts :
| Verdict | Ce qui est arrivé | Ce que cela signifie |
|---|---|---|
| Prouvé | Honeypot vide, preuve présente | Un navigateur a affiché le formulaire et une personne l’a envoyé. |
| Déclenché | Honeypot rempli | Un robot a rempli chaque champ trouvé. |
| Échoué | Champ d’ancrage présent, preuve absente | La page a été chargée, mais le script du navigateur ne s’est jamais exécuté. |
| Absent | Aucun champ | Le formulaire n’avait aucun champ de protection, par exemple une ancienne page en cache ou un thème avec son propre balisage de commentaires. |
« Absent » est traité avec indulgence, car il a des causes inoffensives. Un thème qui écrit lui-même son formulaire de commentaires sans les hooks WordPress habituels n’est jamais traité comme un robot.
Ce qu’il advient d’un envoi refusé
- Honeypot rempli : l’envoi est refusé avec « Your submission was not accepted. Please reload the page and try again. ». Hive le journalise, le compte aussitôt dans l’échelle de blocage progressive et, en mode Community Network, signale l’adresse à la communauté. Les adresses en liste blanche et les utilisateurs qui peuvent modifier des articles en sont exemptés.
- Preuve absente sur un commentaire : le commentaire est refusé avec « This form needs JavaScript to be submitted. Switch it on and try again. ». L’adresse est journalisée mais jamais comptée ni bloquée, car un lecteur sans JavaScript n’est pas un attaquant.
- Preuve absente à l’inscription ou à la réinitialisation du mot de passe : le formulaire refuse et indique pourquoi. Le message de réinitialisation renvoie aussi vers un autre administrateur ou WP-CLI, au cas où quelqu’un serait déjà bloqué.
- Tout le reste : les commentaires passent aussi par le filtre anti-spam des commentaires, qui examine les liens, les noms et d’autres signes de spam. Le sort d’un commentaire signalé se règle avec Action on a comment scored as spam : marquer comme spam (par défaut), bloquer ou désactivé.
Chaque refus apparaît dans l’Event Log sous ReportedIP Hive > Activity, vous voyez donc à tout moment quelle adresse a été arrêtée et pourquoi.
Quels formulaires sont protégés dans quelle formule
| Formulaires | Formule |
|---|---|
| Formulaire de commentaires, inscription WordPress et WooCommerce, réinitialisation du mot de passe | Toutes les formules, y compris Free |
| Contact Form 7 | Toutes les formules, y compris Free |
| Vérification par calcul en plus de la preuve | À partir de Professional |
| Gravity Forms, WPForms, Forminator, Formidable Forms, Elementor Forms, Ultimate Member | À partir de Business |
La vérification par calcul comble une faille que la preuve simple laisse ouverte : un script qui lit le nom du champ dans la page et le renvoie. Avec elle, le navigateur doit résoudre une petite tâche signée de votre propre site avant l’envoi, et chaque tâche n’est acceptée qu’une fois. Le détail pour chaque extension de formulaires figure dans les guides consacrés à Gravity Forms et à WPForms et Forminator.
Comment activer la protection
Ouvrez ReportedIP Hive > Protection et la carte Form Protection. Sur une nouvelle installation, Comment honeypot, Form execution proof et l’interrupteur de Contact Form 7 sont déjà activés. Le champ honeypot n’apparaît dans le formulaire que tant que Form execution proof est activé : laissez donc les deux activés ensemble.
Avec l’Expert mode activé, la carte affiche aussi Apply the proof to sign-up and password reset, Computation check on forms et Action on a comment scored as spam. Si vous voulez observer avant de refuser, activez Report-only mode dans la carte Blocking & Escalation : Hive journalise alors chaque refus et ne refuse rien. Pour tester la protection, Tools > Diagnostics (visible en Expert mode) lance trois passages avec votre propre navigateur, comme un visiteur, comme le même visiteur deux fois et comme un robot, sans envoyer de vrai formulaire.
Accessibilité, cache et confidentialité
Le honeypot est conçu pour qu’aucune personne ne trébuche dessus. Il porte aria-hidden="true", ce qui le cache aux lecteurs d’écran selon WAI-ARIA, il est retiré de l’ordre de navigation au clavier et exclu du remplissage automatique, et son libellé caché indique « Leave this field empty ».
Rien de propre à la requête n’arrive dans le HTML, les caches de pages complètes comme WP Rocket, LiteSpeed ou un CDN continuent donc de servir la même page. Le script mesure aussi combien de temps le formulaire est resté à l’écran et envoie ces secondes ; cette valeur est journalisée avec un refus. Il n’y a ni cookies, ni empreinte, ni requête vers un tiers. En mode Local Shield, rien ne quitte votre site. En mode Community Network, l’adresse d’un robot qui a rempli le honeypot est signalée à reportedip.com, et avec Community threat check on forms activé, l’adresse du visiteur y est vérifiée avant l’acceptation d’un commentaire, d’une inscription ou d’une réinitialisation de mot de passe. Le guide de confidentialité détaille les deux modes.
Questions sur le honeypot de formulaire WordPress
Le honeypot peut-il bloquer un vrai visiteur ?
Un vrai visiteur ne voit jamais le honeypot, une personne ne peut donc pas le remplir par erreur. Seuls les lecteurs dont JavaScript est désactivé remarquent quelque chose : leur commentaire est refusé avec un message clair leur demandant de l’activer. Leur adresse n’est jamais comptée pour un blocage, car l’absence de JavaScript seule n’est pas considérée comme une attaque.
Faut-il encore un captcha avec le honeypot de Hive ?
La plupart des sites n’ont plus besoin de captcha. Le honeypot arrête les robots qui remplissent tous les champs, la preuve d’exécution arrête les scripts qui envoient directement à l’adresse du formulaire, et la vérification par calcul, à partir de Professional, stoppe aussi les scripts qui copient les noms de champs. Un captcha n’a plus d’intérêt que pour des formulaires attaqués à la main par des personnes.
Le honeypot fonctionne-t-il avec le cache de pages ?
Le honeypot fonctionne avec le cache de pages, car le balisage du formulaire est identique pour chaque visiteur. Le champ de preuve est ajouté par un script dans le navigateur, pas par le serveur, une page en cache reste donc valable. Après une mise à jour de l’extension ou l’activation d’une extension de formulaires, Hive accorde un délai de grâce aux pages en cache pour que personne ne soit refusé à cause d’une ancienne copie.
À lire ensuite
La documentation de Hive détaille la détection des robots et le spam de commentaires ainsi que le cache et la compatibilité. Toutes les autres fonctions sont expliquées dans les guides de ReportedIP Hive.