Un formulaire peut envoyer du spam alors que l’interface semble protégée. À l’inverse, un réglage anti-bot peut arrêter des visiteurs légitimes ou empêcher un moteur de lire une page. Cet atelier propose une méthode : observer le chemin complet, modifier une couche à la fois et valider les usages réels. Il ne fournit pas une valeur universelle de pare-feu à appliquer à tous les sites.
Guide préparé le 30 septembre 2026. Aucun réglage de ton site n’est modifié par cet article. Les commandes sont des exemples à adapter au chemin réel et à exécuter avec un compte autorisé ; les validations proposées restent à réaliser sur ton installation.
Télécharger le mémo : WordPress, anti-spam et accès des moteurs
1. Cartographier le vrai chemin du formulaire
Pars d’un email indésirable : note sa date, son objet, la page et le module qui l’a produit. Un formulaire de contact, un livre d’or et des commentaires peuvent utiliser trois traitements différents. Le nom affiché de l’expéditeur ne prouve pas l’origine. Corrèle l’exemple avec les journaux du site et la soumission enregistrée, en masquant les données personnelles dans ton dossier de travail.
Dessine la chaîne : navigateur, cache/CDN éventuel, proxy, pare-feu, WordPress, module de formulaire, traitement serveur, enregistrement puis envoi. Note le point de réception : requête vers une page, REST ou AJAX. Un captcha visible à l’écran ne prouve pas que le traitement serveur exige sa réussite. Un ancien endpoint encore actif peut aussi contourner un nouveau formulaire.
Pour l’atelier, choisis un seul formulaire et crée une fiche « avant » : URL, nom et version du module, règle existante, nombre de soumissions acceptées et refusées sur une période définie. Ne conserve pas inutilement le contenu intégral des messages dans les logs. Ta mesure utile est autant le taux de demandes légitimes perdues que le volume de spam reçu.
2. Préparer une modification récupérable
La documentation de sécurité WordPress insiste sur les mises à jour, les sources fiables, la limitation des accès et la préparation d’une récupération. Commence par sauvegarder fichiers et base, puis vérifier que la sauvegarde est restaurable. Reproduis le formulaire dans une préproduction privée ; les emails de cette copie doivent être capturés ou bloqués pour éviter d’écrire à de vrais visiteurs.
Prépare un petit plan de changement : réglage précis, raison, résultat attendu, test et retour arrière. Exemple : « activer la validation serveur du champ piège du formulaire contact ». C’est vérifiable. « renforcer tout l’anti-spam » est trop vague pour comprendre une régression. Programme les changements à un moment où tu peux rester disponible et comparer avec la fiche initiale.
3. Faire un inventaire en lecture seule avec WP-CLI
Sur un serveur Linux où WP-CLI est déjà installé, remplace /srv/www/site par le chemin vérifié. Exécute ces commandes sous le compte du site, sans afficher les secrets de wp-config.php. Elles interrogent l’état ; elles ne lancent pas de mise à jour :
wp --path=/srv/www/site core version
wp --path=/srv/www/site plugin list --fields=name,status,version,update --format=table
wp --path=/srv/www/site theme list --fields=name,status,version,update --format=table
wp --path=/srv/www/site user list --fields=ID,user_login,roles --format=table
wp --path=/srv/www/site option get blog_public
wp --path=/srv/www/site core verify-checksums --include-rootLa vérification des sommes de contrôle du cœur compare les fichiers à ceux de WordPress.org, avec un accès réseau nécessaire. Un succès ne couvre pas toutes les extensions, le contenu de la base ni tous les logiciels du serveur. Un fichier supplémentaire peut être légitime ; enquête avant de le retirer. Les autres commandes chargent WordPress et peuvent déclencher du code de modules : elles ne constituent pas une méthode d’analyse hors ligne d’un site suspect.
Relie cet inventaire à tes rôles : le compte qui écrit des articles a-t-il besoin d’installer des extensions ? Un compte dormant appartient-il encore à quelqu’un ? Pour les composants inutilisés, prépare leur retrait après vérification de leurs dépendances. Pour les mises à jour, teste formulaires, affichage et intégrations en préproduction avant le passage au site public.
4. Protéger chaque soumission sur le serveur
Le guide OWASP de validation des entrées distingue contrôle navigateur et contrôle serveur. JavaScript aide l’utilisateur ; le serveur doit vérifier les données avant l’envoi ou l’enregistrement. Définis des tailles compatibles avec les messages attendus, des champs obligatoires utiles et un traitement adapté au contenu affiché. Un nom avec apostrophe, un accent ou une adresse avec un signe « + » ne doit pas devenir du spam par principe.
Un honeypot est un champ piège que les humains ne sont pas censés remplir. Active celui du module s’il existe, puis teste son accessibilité et les gestionnaires de remplissage automatique. Il faut que le serveur refuse ou mette en quarantaine les soumissions concernées. Le masquer en CSS sans vérifier sa valeur ne crée aucune protection de traitement.
Un défi anti-bot doit aussi être vérifié côté serveur et échouer proprement quand sa preuve est absente, expirée ou invalide. Vérifie la compatibilité avec le cache de page : une page servie longtemps peut embarquer un jeton périmé. Les durées minimales de remplissage et les règles de contenu sont des indices complémentaires ; ni un message court ni un nom inhabituel ne prouvent à eux seuls qu’une personne est un robot.
Un nonce WordPress aide à contrôler certains scénarios de requêtes croisées ; il ne remplace ni une autorisation, ni une protection anti-spam. Sa présence seule n’identifie pas un humain.
5. Adapter les limites au parcours plutôt qu’au chiffre magique
Le guide OWASP anti-automatisation propose plusieurs signaux et couches de contrôle. Une limite sur l’envoi d’un formulaire peut être différente de celle appliquée aux pages publiques ou à la connexion. Choisis les seuils à partir d’observations : demandes habituelles, rafales, réseau partagé et capacité du serveur. Une seule IP peut représenter plusieurs personnes derrière une école ou une entreprise.
Dans ton plan de test, indique ce qui doit se produire en cas de limite : ralentissement, rejet temporaire compréhensible ou mise en quarantaine. Mesure le retour à la normale. Vérifie aussi quelle adresse le proxy transmet et quels intermédiaires sont autorisés à la déclarer ; faire confiance à n’importe quel en-tête fourni par le client permettrait de contourner la règle.
6. Préserver l’accès des moteurs sans accepter les imposteurs
Les articles publics, feuilles de style utiles, rubriques et sitemap doivent rester accessibles. Un formulaire public à lire n’impose pas d’autoriser son envoi sans contrôle. Un robot qui déclare « Googlebot » dans son User-Agent n’est pas identifié pour autant : Google documente la vérification par DNS et par plages d’adresses publiées.
Contrôle la réponse HTTP finale, robots.txt, les balises robots, les en-têtes X-Robots-Tag et les URL canoniques. Une page publique utile ne doit pas aboutir à une page de connexion ou à un défi JavaScript inaccessible aux moteurs. Une préproduction, au contraire, doit rester privée ; ne recopie pas aveuglément ses réglages d’indexation sur le site public.
Un test avec un faux User-Agent vérifie seulement la règle associée à cette chaîne. Il ne prouve pas que le vrai Googlebot est autorisé. Utilise les journaux pour identifier les requêtes vérifiées et le test en direct d’une URL dans Search Console si tu disposes de la propriété. Une lecture réussie ou une demande d’indexation ne garantit ni l’indexation ni la position dans les résultats.
7. Atelier de validation : six cas et leurs résultats
| Cas | Résultat attendu |
|---|---|
| Message normal, accents et apostrophe | Confirmation visible ; une seule réception |
| Adresse invalide ou champ requis absent | Erreur utile ; aucune émission |
| Champ piège rempli | Refus/quarantaine prévu, sans email sortant |
| Preuve anti-bot manquante ou périmée | Refus serveur et possibilité de recommencer |
| Petite rafale contrôlée puis attente | Limite observée et récupération après le délai prévu |
| Article, rubrique et sitemap publics | Réponse correcte, contenu lisible, absence de défi inattendu |
Réalise uniquement une rafale limitée et autorisée, sans test de charge sauvage. Ajoute mobile, clavier et remplissage automatique aux cas humains. Une confirmation affichée ne suffit pas : corrèle soumission, traitement et message reçu. Si le formulaire reste silencieux, inspecte sa requête et son retour réseau ; ne présume pas que l’envoi a réussi.
8. Publier le réglage et surveiller la régression
Quand ces cas passent, applique un seul changement au site public, puis refais le parcours de contact avec un message identifié. Observe sur une période comparable les refus, spams reçus, demandes réelles et erreurs HTTP. Si un cas utile échoue, reviens au réglage documenté plutôt que désactiver toutes les protections. Conserve la date, le module et le résultat des essais pour les prochains changements.
Sources
Documentation consultée le 30 septembre 2026 : sécurité WordPress, WP-CLI et intégrité du cœur, OWASP : validation, OWASP : anti-automatisation et Google : vérification des robots. Pour préparer le retour arrière : l’atelier de restauration WordPress.