Protection anti-spam pour Gravity Forms sans captcha
La protection anti-spam de Gravity Forms sans captcha signifie que le site vérifie qu’un véritable navigateur a affiché et envoyé le formulaire, au lieu de demander au visiteur de le prouver. C’est exactement ce que fait ReportedIP Hive pour Gravity Forms : l’envoi par un bot est refusé et signalé comme une erreur de validation au-dessus du formulaire, aucune donnée n’est enregistrée, et un véritable utilisateur ne voit jamais de puzzle, d’image ou d’étape supplémentaire.
L’adaptateur Gravity Forms fait partie de la formule Business et s’active à l’aide d’un bouton situé sur la page « Protection », dans la section « Protection des formulaires ». Il a été introduit avec la version 2.1.63 de Hive et a été testé avec Gravity Forms 3.1.
Pourquoi un captcha n’est pas l’outil adapté à un formulaire de contact
Un captcha impose cette tâche à la mauvaise personne. L’expéditeur, qui souhaite vous contacter, doit déchiffrer des lettres déformées ou cliquer sur des feux tricolores ; le script qui inonde le formulaire n’a jamais eu l’intention de le résoudre et passe simplement à un site dont le captcha est moins complexe. Chaque tentative infructueuse vous coûte un message, et vous ne savez jamais combien de personnes ont abandonné.
Les bots se répartissent en deux catégories, et un formulaire doit pouvoir gérer les deux. Le premier remplit tous les champs qu’il trouve, y compris ceux qu’il devrait ignorer. Le second ne charge jamais la page : il envoie directement une requête à l’Endpoint avec une Payload copiée à partir d’une soumission réelle. Gravity Forms intègre son propre champ « Honeypot » pour le premier groupe. Le second passe à côté du « Honeypot », car il n’affiche jamais le code qui le contient.
Comment la « preuve d’exécution » évalue un formulaire soumis via Gravity Forms
Hive insère un champ d’ancrage invisible dans chaque formulaire Gravity Forms présent sur la page ; ce champ est exclu de l’ordre de navigation et n’est pas détecté par les lecteurs d’écran. Un petit script ajoute ensuite un deuxième champ dont le nom varie à chaque installation, de sorte qu’une Payload enregistrée sur un site ne correspond à aucun autre. Lors de la soumission, le serveur lit ces deux champs et classe la requête dans l’une des quatre catégories suivantes :
| Verdict | Ce que contenait l’envoi | Que se passe-t-il ? |
|---|---|---|
proved | Ancrage vide, champ de vérification présent | Un navigateur a affiché le formulaire et a exécuté son script. La saisie a été enregistrée. |
tripped | Le champ d’ancrage, renseigné | Refusé. Un champ invisible renseigné correspond à une automatisation pour laquelle il n’existe aucune explication valable, et l’adresse monte dans l’échelle de blocage. |
failed | Ancrage vide, champ de validation manquant ; le site sait qu’il affiche ce champ | Refusé. La page a été récupérée, mais le script ne s’est jamais exécuté. |
absent | Aucun des deux champs n’est renseigné | Indulgent. Hive n’a pas encore constaté qu’il affiche lui-même le champ sur ce site, rien n’est donc jugé. |
Aucun élément spécifique à la requête n’est transmis au code HTML. L’ancre reste la même à chaque chargement de la page, le nom aléatoire est défini dans le script ; ainsi, le cache de la page peut continuer à servir le formulaire aussi longtemps qu’il le souhaite sans qu’aucun visiteur ne se retrouve bloqué.
Gravity Forms envoie ses formulaires de manière autonome
La plupart des plugins de formulaire effectuent la soumission via l’événement « submit » standard du navigateur ; c’est à ce moment-là que le script de Hive remplit le champ de validation. Ce n’est pas le cas de Gravity Forms : il collecte et envoie le formulaire de manière autonome, sans déclencher d’événement de soumission. Il publie toutefois un filtre JavaScript prévu précisément pour ce moment, gform/submission/pre_submission, le même que celui utilisé par son propre captcha invisible. Hive se connecte à ce filtre, remplit le champ de vérification, puis renvoie le formulaire.
Sur le serveur, l’ancre est intégrée via gform_form_tag, de sorte qu’elle se trouve à l’intérieur de l’élément form sans rechercher de balise de fermeture dans le code, et le verdict est rendu via gform_validation, le hook que Gravity Forms exécute à chaque soumission avant d’enregistrer une entrée.
Les formulaires comportant plusieurs pages ne sont évalués qu’une seule fois, à la dernière page
Un formulaire comportant plusieurs pages envoie chaque page sous forme de requête distincte. Seule la dernière page constitue un envoi ; c’est donc la seule qui est évaluée. Évaluer chaque étape entraînerait inutilement le calcul d’une réponse et une recherche dans la base de données communautaire. Les formulaires envoyés en arrière-plan, selon le mode AJAX utilisé par la plupart des sites, sont traités de la même manière qu’un formulaire envoyé lors du rafraîchissement de la page, et le message de refus s’affiche au-dessus du formulaire dans les deux cas.
Un formulaire remis en retard est à nouveau accepté
Un formulaire Gravity Forms affiché une deuxième fois, à la suite d’une validation échouée ou dans une fenêtre contextuelle, arrive après le premier passage du script. Hive écoute l’événement de rendu propre au plugin et traite à nouveau le formulaire : il lit le défi, redémarre le chronomètre et applique le filtre de soumission. Avant la version 2.1.63, un tel formulaire ne trouvait aucune réponse calculée en attente et était refusé car non validé ; ce problème a été corrigé.
Pourquoi une soumission refusée est considérée comme une erreur de validation et non comme un message envoyé dans le dossier « spam »
Gravity Forms propose un dossier « spam », et l’adaptateur aurait pu y classer les soumissions refusées. Or, il ne le fait pas, et ce, délibérément. Un message placé dans le dossier « spam » est un message pour lequel l’expéditeur a reçu un message de remerciement, mais que l’administrateur ne lit jamais. Si la décision était erronée, la personne qui vous a écrit pense que son message est bien parvenu et attend une réponse qui ne viendra jamais.
Un refus de la part de Hive correspond en réalité à une erreur de validation au niveau du formulaire, selon le même mécanisme que celui utilisé par Gravity Forms pour sa propre règle « au moins un champ doit être renseigné ». L’expéditeur voit le message s’afficher au-dessus du formulaire, peut en comprendre la raison et peut réessayer. Aucune entrée n’est enregistrée, aucune notification n’est envoyée et aucune page de confirmation n’est affichée. Ce plugin ne perd jamais un message sans au moins en informer l’expéditeur.
Ce que voit un robot et ce que voit un visiteur
| Véritable visiteur | Script qui poste directement sur l’Endpoint | Un bot qui remplit tous les champs | |
|---|---|---|---|
| Charge la page | Oui | Non | Oui |
| Exécute le script | Oui | Non | En général, non |
| Champ de vérification | Présent | Absent | Manquant ou erroné |
| Champ d’ancrage | Vide | Vide ou manquant | Rempli |
| Étape supplémentaire pour l’humain | Aucun | ||
| Résultat | Entrée enregistrée | Refusé au-dessus du formulaire | Refusé, adresse prise en compte |
Ce que ce contrôle ne permet pas de faire, c’est de distinguer une personne d’un botnet pilotant un véritable navigateur. Il permet de distinguer un navigateur d’un script. Pour l’adresse derrière le navigateur, Hive effectue une deuxième vérification indépendante : la vérification des menaces par la communauté refuse toute soumission provenant d’une adresse à laquelle le site refuserait une connexion, selon le niveau de protection imposé par la page de connexion, et l’expéditeur en est informé. Ce contrôle nécessite le mode « Community Network » ; la preuve d’exécution fonctionne également en mode « Local Shield », sans qu’aucune donnée ne quitte le site.
Les soumissions effectuées via l’API Gravity Forms ne sont jamais évaluées
Une importation, un flux Zapier ou un appel REST via l’API de Gravity Forms ne comporte ni ancrage ni champ de validation ; en l’absence de règle spécifique, chacun d’entre eux serait considéré comme un client ayant échoué à la validation. Hive demande au hook de validation si la soumission provient d’un navigateur et ignore tout le reste. Depuis Gravity Forms 2.6.4, le hook l’indique lui-même ; sur une version plus ancienne du plugin, Hive pose la question de la même manière que le « Honeypot » propre au plugin.
Mise en marche en quatre étapes
- Effectuez la mise à jour vers Hive 2.1.63 ou une version ultérieure dans le cadre d’une formule Business. Avec une formule inférieure, le bouton Gravity Forms reste visible et verrouillé, et le nom de la formule requis s’affiche à côté.
- Activez le commutateur « Gravity Forms » sur la page « Protection », dans la section « Protection des formulaires ». Son activation vide les caches de page courants et, pendant 24 heures, une soumission ne comportant pas la preuve est tout de même acceptée ; ainsi, une page mise en cache sans ce champ ne peut empêcher personne d’accéder au formulaire. Le filtre
reportedip_hive_form_adapters_graceoffre une plus grande marge de manœuvre sur un site dont le cache a une durée de vie supérieure à une journée. - Lancez l’autotest dans le menu Outils → Diagnostics. La fiche répertorie les éléments activés, puis effectue trois cycles avec le navigateur que vous utilisez actuellement : en tant que visiteur, deux fois en tant que même visiteur, et en tant que bot. Aucun formulaire n’est réellement envoyé, aucun e-mail n’est expédié et aucune donnée n’est enregistrée. Une protection invisible est par ailleurs difficile à distinguer d’une absence totale de protection.
- Vous pouvez, si vous le souhaitez, démarrer en Report-Only Mode, qui consigne chaque verdict et ne rejette aucune requête. Une semaine de journaux permet de voir ce qui aurait été refusé avant que quoi que ce soit ne le soit.
La vérification par calcul, intégrée à partir de la version Professional et donc également dans la version Business, comble la seule faille que laisse le champ de vérification simple : lire le nom du champ à partir de la page et le renvoyer. Le navigateur effectue un petit calcul en arrière-plan, chaque réponse n’est acceptée qu’une seule fois, et l’expéditeur ne remarque toujours rien. Cette fonctionnalité nécessite le protocole HTTPS ; sans celui-ci, c’est le champ de vérification simple qui continue de décider.
Quels plugins de formulaires bénéficient de la même protection ?
| Formulaire | Plan | Testé par rapport à |
|---|---|---|
| Formulaires de commentaires, d’inscription et de réinitialisation du mot de passe | Gratuit | Noyau WordPress, WooCommerce, Multisite |
| Vos propres formulaires, via l’API des formulaires | Gratuit | Trois appels : field, check, passes |
| Contact Form 7 | Chaque forfait | La version publiée sur WordPress.org |
| Gravity Forms | Business | 3.1, y compris les formulaires de plusieurs pages et les formulaires en arrière-plan |
| Formidable Forms et Formidable Forms PRO | Business | 6.35 |
| Formulaires Elementor | Business | Elementor PRO 3.34 : le widget « Formulaire » n’existe que dans cette version |
| Ultimate Member | Business | 2.13, formulaires de connexion, d’inscription et de mot de passe |
Chaque plugin dispose de son propre commutateur. La couche complète, le commutateur principal, un deuxième commutateur qui exclut l’inscription et la réinitialisation du mot de passe, ainsi que le Report-Only Mode se trouvent tous sur la page « Protection ». REPORTEDIP_HIVE_DISABLE_FORM_PROOF dans wp-config.php permet de désactiver la couche lorsque, par exemple, un visiteur ne parvient pas à valider un formulaire et que vous devez vous assurer du bon fonctionnement du site avant de procéder au débogage.
Foire aux questions
Gravity Forms a-t-il toujours besoin d’un captcha lorsque Hive est activé ?
Pas contre les scripts et les bots. La vérification d’exécution détecte une soumission où le formulaire n’a jamais été affiché et un bot qui remplit le champ invisible, tandis que le contrôle des menaces par la communauté refuse une adresse déjà connue du réseau. Un captcha n’apporte rien de plus à cela, si ce n’est une étape supplémentaire que l’expéditeur doit effectuer. Aucun champ ne permet de distinguer une personne d’un botnet pilotant un véritable navigateur, et un captcha n’y parvient pas non plus.
Est-ce que cela fonctionne en parallèle d’Akismet ou du « Honeypot » de Gravity Forms ?
Oui. Hive évalue la soumission au niveau du hook de validation, avant même qu’une entrée n’existe. Une soumission refusée n’atteint jamais la liste des entrées, le dossier spam ni aucun autre plugin anti-spam. Tout ce qui passe cette étape est ensuite soumis aux vérifications que vous effectuez déjà.
Que se passe-t-il pour un visiteur dont JavaScript est désactivé ?
Dans le cas des plugins de formulaire, une soumission sans justificatif est refusée avec un message expliquant pourquoi, car un formulaire de contact ne dispose pas de file d’attente de modération sur laquelle s’appuyer. Sur le formulaire de commentaires, le même cas ne nécessite qu’une étape de modération. Un site accueillant de nombreux visiteurs de ce type peut exécuter la couche en Report-Only Mode, ou désactiver l’option Gravity Forms et conserver les formulaires gratuits.
Cette vérification ralentit-elle le formulaire ou perturbe-t-elle la mise en cache des pages ?
Non. L’ancrage est identique à chaque chargement de la page et aucune information spécifique à la requête n’est transmise au code HTML ; une page mise en cache reste donc valide. Le script remplit un champ au moment de la soumission et mesure la durée d’affichage du formulaire à l’écran ; le point de départ provient du navigateur, jamais du code source, de sorte qu’une page mise en cache ne peut pas contenir de données obsolètes.
Est-ce conforme au RGPD ?
La vérification ne recueille aucune information sur le visiteur, si ce n’est la présence ou non de deux champs masqués lors de l’envoi du formulaire et le nombre de secondes pendant lesquelles le formulaire est resté affiché à l’écran. Pas d’empreinte numérique, pas de requête vers des tiers, pas d’image provenant d’un autre domaine. En mode « Local Shield », aucune donnée ne quitte le site. La documentation du plugin WordPress contient un résumé complet du traitement des données.
Lectures complémentaires
- Honeypot et preuve d’exécution : les quatre verdicts et l’évaluation qu’en fait le formulaire de commentaires
- Decoy Paths : un autre type de piège qui signale la présence d’un scanner dès sa première exploration
- Audit Event Trail, l’autre fonctionnalité Business qui a été intégrée une version plus tôt
Consultez la documentation du plugin WordPress pour obtenir la liste complète des paramètres et comparer les formules afin de découvrir ce que comprend la formule « Business ». Découvrez ReportedIP Hive →