WordPress a une particularité qui attire autant que ça gêne : il est très répandu, donc très ciblé. Le spam s’installe vite, les tentatives d’intrusion aussi, et la plupart des sites ne souffrent pas d’un seul problème, mais d’une accumulation discrète. Une page de contact mal protégée, un formulaire d’inscription trop permissif, des identifiants qui circulent, un thème ou un plugin laissé en friche, puis une vague qui ressemble à du “bruit” jusqu’au jour où elle devient un blocage, une saturation, ou pire.
Une approche efficace ne consiste pas à “tout verrouiller au maximum” au détriment de l’usage. Elle consiste plutôt à réduire la surface d’attaque, filtrer le trafic avant qu’il n’arrive au PHP, https://gardewp.fr/securite-wordpress/ durcir l’application, et garder un œil sur ce qui change. Je l’ai vu maintes fois sur le terrain: les sites qui tiennent dans le temps ne sont pas ceux qui ont le moins de tentatives, ce sont ceux qui encaissent mieux et réagissent vite.
Commencer par distinguer spam et attaques
Avant de configurer la moindre règle, il faut clarifier le type de nuisances. Le spam, ce sont des comportements qui cherchent à obtenir quelque chose: des backlinks, des envois de formulaires, des inscriptions, des commentaires, parfois de l’email harvesting. Une attaque, c’est plus agressif: tentative d’authentification, exploitation de vulnérabilité, injection, téléchargement de charge utile, modification de fichiers, ou mouvement latéral.
Sur WordPress, ces mondes se mélangent. Par exemple, une campagne de commentaires peut aussi servir de test pour détecter les protections, une vague d’URL peut chercher à déclencher des endpoints vulnérables, et une salve de tentatives de login peut masquer des scans sur des fichiers sensibles.
Quand je travaille sur un site, je commence par regarder les journaux (ou au minimum les traces serveur et applicatives): types de requêtes, fréquences, chemins visés, user agents, et erreurs HTTP. Si vous voyez surtout des POST sur wp-comments-post.php ou des formulaires, vous êtes davantage dans le spam applicatif. Si vous voyez des tentatives d’accès à des répertoires, des scripts inhabituels, des scans sur /wp-admin/ avec une cadence anormale, vous êtes dans l’attaque.
Cette étape ne sert pas à “cataloguer” pour le plaisir. Elle sert à appliquer des protections adaptées, sans tirer à l’aveugle.
Ce qui marche le mieux: bloquer tôt, filtrer, puis durcir
Une règle d’or en sécurité WordPress: plus vous bloquez tôt, moins vous payez le coût du traitement. Si le trafic malveillant arrive au serveur applicatif, il consomme du temps CPU, de la RAM, et parfois des ressources liées à WordPress (base de données, plugins, hooks). Le spam et certaines attaques finissent alors par dégrader la performance, ce qui peut ensuite favoriser d’autres incidents (mauvaises réponses, timeouts, redémarrages, erreurs temporaires).
L’approche la plus saine en pratique se décompose en trois étages.
Le premier étage, c’est le filtre avant WordPress: un pare-feu applicatif, un proxy, ou au minimum une protection au niveau serveur (règles de requêtes, limitation de taux, blocage d’IP ou de pays seulement si c’est réaliste pour votre audience). Selon votre hébergement, vous aurez plus ou moins d’options.
Le deuxième étage, c’est WordPress lui-même: durcissement des endpoints, limitation des tentatives de connexion, hygiène des formulaires, réduction de ce qui est exposé publiquement.
Le troisième étage, c’est l’observabilité: vous devez pouvoir répondre à la question “qu’est-ce qui s’est passé ?” sans courir après des logs introuvables. Les protections sont utiles, mais elles deviennent réellement efficaces quand vous savez si elles fonctionnent.
Séparer le “bruit” du risque réel dans les plugins
Sur WordPress, beaucoup de sites installent “un plugin anti-spam” puis “un plugin anti-malware” puis “un plugin de sécurité”. Le problème, ce n’est pas le nombre de plugins en soi, c’est la superposition des mécanismes sans visibilité: deux plugins peuvent chacun modifier .htaccess, ajouter des règles, ou gérer les mêmes formulaires, et on finit par ne plus savoir qui est responsable quand quelque chose casse.
Mon conseil, issu de situations où des formulaires ont cessé de fonctionner du jour au lendemain: choisissez peu d’éléments, mais cohérents. Un bon plugin anti-spam sur les formulaires et les commentaires peut suffire, si les champs sont gérés correctement et si le site est déjà bien configuré. Pour la sécurité globale, cherchez des mécanismes qui vous intéressent vraiment: blocage basé sur des patterns de requêtes, durcissement login, protection des fichiers, et surtout des journaux lisibles.
Un autre point pratique: les plugins de sécurité agressifs peuvent gêner des outils légitimes. Je pense aux robots de monitoring, aux systèmes d’e-mailing, aux formulaires qui envoient des données depuis une appli mobile, ou aux plugins de caching. Un durcissement trop “intrusif” se voit vite dans les taux d’échec. Si vous devez choisir, préférez la protection “détecter et freiner” plutôt que “rejeter sans explication”.
Durcir l’accès: login, xmlrpc, et surface exposée
Les tentatives d’accès sont souvent la partie la plus constante des attaques automatiques. Sur WordPress, deux cibles reviennent très souvent: la page de connexion et xmlrpc.php. XML-RPC a servi longtemps pour la compatibilité avec des clients distants, et même si certains besoins existent encore, beaucoup de sites peuvent le désactiver sans impact majeur.
La sécurité WordPress, ce n’est pas seulement “empêcher d’entrer”. C’est réduire la quantité de choses à exploiter et rendre les erreurs plus faciles à diagnostiquer.
Sur la connexion, la stratégie la plus efficace combine plusieurs éléments:
- une limitation de taux sur les tentatives un verrouillage temporaire après échecs répétés une détection du trafic anormal un durcissement côté mots de passe et comptes
Le piège classique, c’est de compter uniquement sur le “mdp solide”. Ça aide, mais ça ne protège pas contre les attaques par brute force quand il existe des comptes faibles, des utilisateurs avec des identifiants réutilisés, ou des fuites de données antérieures. Les limitations de taux réduisent mécaniquement la vitesse des essais et donnent du temps à vos mécanismes de détection.
Concernant xmlrpc.php, l’idée est de vérifier votre besoin. Si vous utilisez des fonctionnalités comme des notifications ou des publications distantes, désactiver peut casser des usages. Si vous ne l’utilisez pas, le désactiver est souvent un gain net.
Protéger les formulaires: là où le spam vit et prospère
Le spam a un “talon d’Achille” sur WordPress: les formulaires. Commentaires, formulaires de contact, inscription, réinitialisation de mot de passe, formulaires d’abonnement. Beaucoup d’attaques ne visent pas à pirater, elles visent à envoyer. Et pour envoyer, il faut une surface.
Le premier levier n’est pas forcément un plugin. Il s’agit de rendre le formulaire moins exploitable:
- champs inutiles supprimés validations côté serveur (pas seulement côté navigateur) limitation de fréquence par adresse IP et par session gestion des erreurs sans révéler de détails excessifs
Ensuite viennent les protections anti-bot: CAPTCHA adapté au niveau de risque, honeypot (un champ invisible rempli par les bots), et filtrage du contenu. Certains plugins gèrent cela correctement, d’autres ajoutent des CAPTCHA lourds qui dégradent l’expérience utilisateur. Le bon choix dépend de votre volume de trafic et du type de formulaire.
Une anecdote fréquente: après une migration, un formulaire “rapide” continue de fonctionner pour les humains, mais les robots se mettent à l’utiliser massivement. Le plus souvent, la migration a changé l’URL, la structure des champs, ou la configuration d’envoi. Sans ajuster la protection, le spam revient, parfois avec plus de volume que sur l’ancien site, car la campagne a simplement trouvé un nouvel endpoint “facile”.
Mettre en place une stratégie de blocage raisonnée
Bloquer “tout” est rarement réaliste. Vous risquez de bloquer des utilisateurs légitimes, notamment si votre audience est internationale et si vous avez un trafic qui varie beaucoup. Sur un site qui vit de formulaires, un blocage trop large peut transformer une campagne marketing en suite de messages “échec d’envoi”.
Le bon compromis, c’est un blocage gradué. Les mécanismes typiques ressemblent à ceci: d’abord une friction (limitation de taux), puis un blocage temporaire en cas de schéma répété, enfin une interdiction plus persistante si le pattern confirme l’intention.
Concrètement, quand je mets en place une politique anti-spam et anti-attaques, je cherche à éviter deux extrêmes: laisser passer trop, ou casser le site. Pour décider, j’observe les journaux et je ajuste sur une base de temps courte, quelques jours, pas uniquement “tout de suite”.
Voici une mini-checklist que j’utilise avant d’ouvrir le robinet des restrictions.
- Activer la limitation de tentatives de connexion (avec durée et seuil raisonnables) Désactiver xmlrpc.php si inutile Ajouter une protection anti-spam sur les formulaires (honeypot ou CAPTCHA léger) Exiger des validations côté serveur cohérentes pour tous les champs
Cette liste ne remplace pas le paramétrage de précision, mais elle évite les trous fréquents.
Utiliser un pare-feu web et des règles qui ont du sens
Selon votre hébergement, vous pouvez avoir un WAF, des règles “anti-bots”, ou simplement un système de filtrage par IP. L’important n’est pas la technologie exacte, c’est la qualité des règles.
Un WAF efficace:
- corrèle des patterns de requêtes (chemins, méthodes, paramètres) applique des limites de taux bloque les attaques connues sans dépendre d’une signature unique conserve des logs exploitables
Le point de vigilance: certaines règles trop générales peuvent bloquer des pages “API” ou des outils de génération statique, et surtout, elles peuvent mettre en erreur de fausses catégories. J’ai déjà vu des règles censées bloquer les bots bloquer en réalité des navigateurs mobiles via un proxy d’entreprise.
Si vous utilisez des règles géographiques, faites-le avec prudence. Sur des sites B2B, le trafic peut venir de partout. Bloquer un pays parce que “ça ne devrait pas être chez vous” peut se retourner contre vous. En revanche, si votre site est clairement local et que les pays non pertinents ne représentent quasiment aucun trafic, vous pouvez réduire le bruit. Le tout est de mesurer.
Sécuriser les comptes et les rôles, c’est aussi anti-spam
Le spam “pur” n’utilise pas toujours un accès. Mais dans beaucoup de cas, une compromission partielle commence par les comptes. Les attaquants cherchent des mots de passe faibles, des comptes dormants, des utilisateurs avec trop de droits, ou des rôles mal calibrés.
Une bonne hygiène:
- supprimer les comptes inutiles utiliser des rôles au plus juste forcer des mots de passe uniques limiter les admins aux personnes vraiment nécessaires surveiller les changements de rôles et de profils
Le spam peut aussi exploiter des comptes compromis pour publier du contenu en masse, injecter des liens, ou modifier des paramètres de formulaires. Si vous avez déjà eu une attaque qui ressemble à un “site qui écrit tout seul”, c’est souvent de ce côté qu’il faut regarder.
Dans les environnements où plusieurs personnes administrent, il est utile de savoir qui a fait quoi. Les plugins et les systèmes de journalisation peuvent aider, mais surtout, gardez une méthode interne de validation: une modification de thème, un ajout de plugin, une mise à jour, tout cela doit avoir une trace. Pas pour la conformité, pour l’investigation.
Patcher sans paniquer: mises à jour et fenêtres de maintenance
WordPress, c’est un écosystème. Le spam et les attaques ne frappent pas forcément votre installation WordPress elle-même, ils frappent souvent un point de passage: un plugin vulnérable, un thème, ou une dépendance.
Le piège est de ne jamais mettre à jour, par peur de casser le site. Résultat: la surface reste vulnérable longtemps. L’autre piège est de mettre à jour en mode “tout de suite, sans vérifier”, puis de découvrir après coup un conflit ou une régression.
Mon approche est pragmatique:
- mettez à jour en premier les composants qui exposent davantage (plugins actifs, plugins de formulaire, plugins d’authentification) vérifiez les pages sensibles (connexion, formulaires, checkout si e-commerce, endpoints API) gardez un test rapide, même simple, pour valider la fonctionnalité
Les journaux d’erreurs et le monitoring de disponibilité valent plus qu’un sentiment de confort. Si votre site devient instable après une mise à jour, corrigez vite, avant que les attaquants ne profitent d’un état dégradé.
Surveiller: logs, alertes, et signaux faibles
Sans surveillance, vous n’avez qu’une impression. L’illusion la plus coûteuse en sécurité, c’est quand tout “semble” normal alors qu’un bot teste votre site depuis une semaine.
Vous voulez des signaux faibles, des éléments qui sortent du bruit:
- pics de 401 ou 403 sur wp-login.php augmentation brutale des POST sur des scripts de formulaire erreurs 404 liées à des chemins inhabituels téléchargements de fichiers nouveaux changements de fichiers plugin ou thème hors cycle de mise à jour
Selon votre stack, vous aurez des logs serveur, des logs applicatifs, ou des exports depuis des plugins. L’essentiel est de rendre ces signaux exploitables.
Voici un second repère, plus opérationnel, pour répondre vite quand “ça sent le problème”.
- Relever la période exacte du pic (heure, date, fuseau) Identifier les URLs et méthodes concernées dans les logs Vérifier les changements récents (plugins, thèmes, fichiers) Contenir immédiatement si nécessaire (désactiver un plugin suspect, changer des paramètres exposés)
Ce déroulé peut être fait en 15 à 30 minutes, même sur un site non technique. L’objectif est d’éviter de perdre une journée à “au cas où” sans diagnostic.
Une protection ne vaut que si elle survit à vos usages
Les meilleures protections sont celles qui ne sont pas contournées par votre propre écosystème. Par exemple, si vous mettez une protection qui bloque trop les requêtes “non browser”, vous allez dégrader une intégration formale. Si vous imposez un CAPTCHA trop dur, vous verrez vos conversions tomber.
J’ai déjà vu un site d’artisan perdre des demandes pendant une période de vacances. Le CAPTCHA était devenu trop exigeant sur certains téléphones, et les tentatives d’envoi échouaient. Les logs montraient un nombre élevé d’échecs, mais rien de “piratage”. La leçon a été nette: testez avec des scénarios réels, et gardez des retours côté utilisateurs.
C’est aussi pour cela que je préfère une combinaison de mécanismes: limiter le taux, filtrer le contenu, et seulement ensuite demander une preuve quand c’est vraiment nécessaire.
L’aspect “fichiers” et la résistance au dérapage
Quand une attaque réussit, c’est rarement parce que WordPress n’a pas “de plugin de sécurité”. C’est parce que les fichiers ont été modifiés ou que du code a été introduit, puis exécuté. Sur WordPress, la défense sur fichiers est plus délicate, car elle dépend de l’environnement (droits d’écriture, mode FTP, déploiement).
Ce que vous pouvez faire, sans tomber dans l’intrusif:
- limiter les permissions d’écriture utiliser des workflows de déploiement propres surveiller les modifications de fichiers (au moins les répertoires wp-content) vérifier les thèmes et plugins installés, leur provenance, et leur cohérence
Si votre hébergeur propose des sauvegardes et une capacité à revenir en arrière facilement, c’est un filet de sécurité concret. Une sauvegarde isolée, testée, est souvent plus utile qu’un outil qui “promet” de tout réparer.
Edge cases: quand le spam disparaît, mais pas vraiment
Une fois en place, certains filtres semblent fonctionner. Puis le spam revient, mais sous une autre forme. Typiquement:
- des messages qui passent parce qu’ils n’attaquent pas le même endpoint des campagnes qui changent le contenu pour contourner les filtres des robots qui s’adaptent au CAPTCHA ou au honeypot
C’est normal. Le spam est une économie, pas un incident. La bonne réponse n’est pas de tout changer tous les jours, mais d’ajuster. Si vous voyez le même pattern, renforcissez. Si le pattern disparaît mais que le volume total reste haut, cherchez d’autres formulaires. Parfois, un formulaire “nouveau” installé pour une action marketing n’a pas reçu la même protection que le formulaire principal.
Une discipline utile consiste à faire le tour des points d’entrée dès qu’on ajoute un plugin ou un formulaire: comment il envoie, comment il valide, et comment il est protégé.
Vérifier votre configuration de base, celle qu’on oublie
On parle beaucoup de plugins, mais la configuration “de base” fait le travail de fond. Par exemple, la façon dont WordPress est exposé, la structure des URL d’admin, le niveau de debug, et les options liées à l’envoi d’email.
Des réglages simples réduisent l’effet des erreurs et limitent les fuites:
- ne pas laisser de debug activé en production vérifier que les envois d’email ne donnent pas d’informations inutiles s’assurer que les pages sensibles ne sont pas accessibles sans contrôle
Ce sont des détails, mais en incident response, ce sont souvent eux qui changent tout: une erreur trop bavarde donne une piste aux attaquants, alors qu’une page plus sobre rend le travail plus difficile.
Mettre en place un plan d’action concret, sans s’épuiser
Si vous devez lancer une démarche réaliste, gardez une logique. Vous pouvez très bien améliorer la situation en quelques jours, sans refaire toute l’infrastructure.
Je recommande de commencer par ce qui réduit le plus le risque immédiat:
- limitation de login et protection de xmlrpc si pertinent protection des formulaires anti-spam durcissement des rôles et suppression des comptes inutilisés surveillance des logs sur une période courte
Ensuite seulement, vous affinez:
- ajustement des règles WAF selon les retours optimisation des mécanismes CAPTCHA ou honeypot vérification des plugins et thèmes installés, suppression de ceux qui ne servent pas
L’objectif n’est pas d’avoir une “forteresse parfaite”. C’est d’atteindre un niveau de robustesse où les attaques ne causent plus de dégâts, et où vous détectez vite quand quelque chose dévie.
Le point final: la sécurité WordPress se pilote, elle ne se subit pas
Le spam et les attaques sur WordPress ne sont pas une fatalité. Ils font partie de la réalité, mais ils ne doivent pas gouverner votre quotidien. Une approche sécurité, c’est une discipline: bloquer tôt, filtrer intelligemment, durcir l’accès, protéger les formulaires, puis surveiller.
Ce qui fait la différence entre un site qui souffre et un site qui résiste, c’est la combinaison. Un seul plugin ne fait pas tout, et une seule règle non plus. En revanche, une stratégie cohérente, même simple, réduit fortement les nuisances et rend les incidents plus rares, moins destructeurs, et plus faciles à corriger.
Si vous partez de zéro, commencez petit mais solide. Si vous êtes déjà équipé, passez en mode diagnostic: regardez les journaux, identifiez le point d’entrée principal, ajustez une protection à la fois, et validez avec des tests réels. WordPress est vivant, votre sécurité aussi doit l’être.