Gérer la sécurité d’un site WordPress, ce n’est pas seulement “installer un plugin de plus”. Dans la pratique, ce qui fait la différence se joue souvent à l’endroit où le trafic arrive et à la manière dont on segmente l’accès. Cloudflare peut devenir un vrai pare-feu, un mécanisme de réduction de surface d’attaque et un outil d’hygiène, à condition de le configurer sérieusement. Et à condition aussi de ne pas casser le site en forçant des règles trop agressives.
Ce texte part d’une logique simple: protéger WordPress là où l’attaquant dépense son premier effort. Les bots visent les pages publiques, devinent des chemins d’administration, testent des formulaires, bombardent des endpoints xmlrpc, essaient des bruteforce. Si Cloudflare absorbe et filtre une partie du bruit avant que la requête n’atteigne PHP, vous gagnez du temps CPU, vous réduisez les logs inutiles et vous diminuez la probabilité d’une intrusion réussie.
Penser “trafic”, pas seulement “serveur”
Quand on parle de sécurité WordPress, on imagine souvent le durcissement interne: droits de fichiers, mises à jour, thèmes propres, plugins limités, authentification renforcée. C’est indispensable, mais ce n’est qu’une moitié du tableau.
L’autre moitié, c’est le trafic. Une requête malveillante ne “devient” dangereuse que si elle parvient suffisamment loin. Cloudflare agit au plus près des internautes, avec une capacité de filtrage globale. En pratique, la configuration la plus utile n’est pas forcément la plus visible. Souvent, ce sont des détails: forcer HTTPS, activer HTTP/2 ou HTTP/3, gérer le mode de compatibilité, bloquer les accès inutiles aux URLs sensibles, vérifier la cohérence des règles de cache, et encadrer l’accès à wp-admin et à wp-login.php.
Je l’ai vu plusieurs fois sur des environnements différents: un site paraît “bien sécurisé” parce que le serveur est propre, puis on découvre que les requêtes arrivent par HTTP, que les logs ne montrent que du bruit, et que les endpoints les plus ciblés sont accessibles sans garde-fou. Une fois que Cloudflare filtre correctement, le volume de tentatives diminue nettement, et l’équipe peut se concentrer sur des incidents réels, pas sur du trafic automatisé.
Activer HTTPS correctement, sans compromis caché
La première base, c’est HTTPS. Mais “activer SSL/TLS” ne veut pas dire “tout laisser par défaut”.
- Veillez à utiliser un mode de chiffrement cohérent avec votre hébergement et vos certificats. L’important est la chaîne complète entre Cloudflare et l’origine. Forcez le redirection vers HTTPS au niveau de Cloudflare, et vérifiez que votre site n’entre pas dans des boucles de redirection. Vérifiez aussi les chemins qui posent problème: login, pages d’API, callbacks de services tiers. Un TLS mal configuré se manifeste rarement sur la page d’accueil, il se manifeste sur des requêtes plus “techniques”.
Une erreur fréquente consiste à configurer un mode “souple” côté Cloudflare alors que l’origine pourrait bénéficier d’un mode plus strict. Côté sécurité, le passage à un niveau plus exigeant réduit certaines classes d’attaques liées à la négociation TLS. Côté exploitation, il faut éviter de rompre des clients plus anciens. Sur un site WordPress, j’ai tendance à privilégier un réglage strict si le parc utilisateur ne requiert pas explicitement une compatibilité legacy.
Comprendre le rôle du proxy Cloudflare
Quand vous mettez Cloudflare en mode proxy sur un enregistrement (souvent “orange cloud”), vous ne gérez plus seulement le DNS. Vous transférez aussi une partie du trafic via le réseau Cloudflare. C’est ce proxy qui permet les fonctionnalités de sécurité: WAF, rate limiting, challenge, filtrage sur des règles, etc.
Mais le proxy change aussi la façon dont votre origine voit l’appelant. Certains headers sont ajoutés par Cloudflare, d’autres sont transmis, et votre configuration WordPress doit en tenir compte. Si vous utilisez un plugin de sécurité ou un reverse proxy local, il peut aussi y avoir des interactions. Le point clé est l’IP réelle.
Si votre configuration ne prend pas en compte les headers “client IP” de Cloudflare, vous risquez de voir des IP Cloudflare dans les logs et de bloquer “la mauvaise cible”. Les blocages deviennent alors inefficaces. C’est un détail qui se voit tard, quand vous essayez de reproduire un incident et que vous n’avez plus de données fiables sur l’IP source.
Sécurité Cloudflare: WAF, règles et gestion du risque
Le Web Application Firewall (WAF) de Cloudflare est utile, mais vous ne devez pas le traiter comme une boîte magique. Un WAF trop strict peut casser des formulaires, des pages de recherche, ou des appels AJAX d’un thème mal conçu. À l’inverse, un WAF trop permissif vous donne une fausse impression de sécurité.
Une approche pragmatique consiste à démarrer avec un mode de protection qui réduit le volume d’attaques sans toucher les flux attendus. Ensuite, vous observez. Les journaux Cloudflare et ceux du serveur aident à distinguer “tentatives de scan” et “vraies erreurs applicatives”.
Je recommande de prendre l’habitude d’observer trois types de trafic: 1) les pics de requêtes répétitives vers wp-login.php, wp-admin, xmlrpc.php, 2) les anomalies d’agent utilisateur et de chemins, 3) les codes HTTP: 401, 403, 404, 429, 5xx.
Quand un site commence à recevoir beaucoup de 403 après un changement, ce n’est pas forcément une mauvaise nouvelle. C’est peut-être le résultat attendu d’un blocage. Mais si ces 403 concernent aussi vos pages normales, c’est un signal d’incompatibilité.
Petit plan de configuration Cloudflare (ciblé, sans sur-casser)
Voici un cadre pratique, à adapter à votre contexte (langue, visiteurs, plugins, intégration e-commerce).
- Activer et forcer HTTPS côté Cloudflare, puis vérifier l’absence de boucle de redirection. Mettre en place un niveau de WAF raisonnable, commencer par un mode moins agressif, puis ajuster après observation. Activer un mécanisme anti-bot ou, à défaut, des règles de challenge sur les endpoints les plus ciblés. Configurer des limites de taux (rate limiting) sur wp-login.php et les endpoints d’authentification. Vérifier la restitution de l’IP client pour que les logs et les blocages correspondent à la réalité.
Cette liste est volontairement courte. Sur le terrain, le plus grand risque n’est pas l’absence de règles, c’est le décalage entre les règles et le comportement réel de votre site.
Sécuriser les endpoints WordPress qui attirent les attaques
Les attaques ne s’étalent pas uniformément. Les automates adorent:
- wp-login.php wp-admin xmlrpc.php les pages qui répondent différemment selon l’état de connexion certains patterns de requêtes qui ressemblent à des tentatives d’exploitation d’anciens thèmes et plugins
Même si vous avez un plugin de sécurité WordPress, il vaut mieux réduire l’exposition de base côté réseau.
Une pratique utile consiste à encadrer l’accès à wp-login.php et à wp-admin via Cloudflare, puis à compléter à l’intérieur de WordPress. Cloudflare peut renvoyer un challenge ou un blocage sur des tentatives trop fréquentes. WordPress, lui, doit continuer d’appliquer des protections sur la logique applicative: limitation des essais, durcissement des formulaires, validation robuste.
La partie délicate est l’expérience utilisateur. Si vous mettez un challenge trop lourd à des endroits trop fréquentés, vous créez des frictions. Une fois, sur un site avec des connexions fréquentes (un back-office partagé par plusieurs rédacteurs), une règle trop stricte a provoqué des échecs intermittents pendant des heures, simplement parce que la latence du challenge était mal tolérée par un navigateur. Le correctif a consisté à limiter le challenge aux tentatives anormales, pas à l’ensemble du trafic.
Gestion du cache: sécurité et performance ne doivent pas s’exclure
Le cache Cloudflare est un levier puissant, mais il peut aussi devenir une source de problèmes si vous oubliez ce qu’il ne doit jamais cacher.
En matière de sécurité WordPress, le piège classique est de laisser un contenu sensible passer au cache, ou de casser des pages dynamiques en forçant un comportement de cache trop agressif. Les pages d’administration et les endpoints d’authentification ne doivent pas être mis en cache de façon inadaptée.
Concrètement:
- Assurez-vous que wp-admin et wp-login.php ne sont pas servis depuis un cache public. Vérifiez les pages qui peuvent varier selon l’utilisateur, par exemple des espaces membre. Testez après chaque changement. Un site qui semble fonctionner peut avoir des fuites plus discrètes, comme une incohérence de redirection ou une erreur intermittente.
Je me fie souvent à un test simple: connecter puis déconnecter, ouvrir les pages sensibles et regarder l’en-tête de réponse. Si vous voyez des signaux de cache publics sur des pages qui devraient être privées, stop. Il faut corriger la stratégie de cache.
Limiter le bruteforce: rate limiting, mais avec discernement
Le bruteforce de connexion est une réalité. Il ne se limite pas à des attaques massives, il se présente aussi sous forme de tentatives “douces”, répétées. Le rate limiting est un bon outil, mais il doit viser les comportements anormaux, pas les utilisateurs légitimes.
Un bon réglage dépend du profil de votre audience:
- Si vous avez beaucoup de trafic et peu de connexions, vous pouvez être plus strict. Si un back-office est utilisé en équipe, vous devez éviter de bloquer des utilisateurs valides derrière des IP sortantes partagées (réseau d’entreprise, NAT, proxy d’un fournisseur).
Cloudflare sait appliquer des règles, mais l’effet final dépend aussi de vos en-têtes de requête, de vos règles d’authentification et de la géographie. Le “bon” chiffre n’est pas universel.
En pratique, je conseille de commencer avec une limite modérée, observer pendant quelques jours, puis ajuster. Le jour où vous mettez une règle très stricte, vous le constaterez le même jour, mais vous ne verrez pas forcément la cause immédiate. Avec une approche progressive, vous gagnez en contrôle.
Encadrer le trafic vers l’origine: “Origin Shield” et cohérence
Selon votre configuration, Cloudflare peut réduire la charge sur l’origine et uniformiser les requêtes via un mécanisme de type Origin Shield (quand disponible dans votre plan et selon votre contexte). Ce type de mécanisme peut être utile, notamment sur des sites avec beaucoup de contenu statique.
Du point de vue sécurité, l’intérêt indirect est clair: moins de requêtes atteignent l’origine pour des contenus qui peuvent être servis depuis le réseau. Moins de charge, moins de surfaces exposées, moins de bruit dans les logs.
Le point d’attention est la cohérence: si vous utilisez une configuration d’accès à l’origine (par exemple des restrictions IP), vous devez vous assurer que Cloudflare passe bien. Sinon, vous aurez des erreurs 5xx ou des comportements https://gardewp.fr/securite-wordpress/ incohérents en fonction des chemins.
WordPress en complément: réduire la surface et renforcer l’authentification
Cloudflare peut filtrer, mais WordPress doit rester robuste. Même en cas de configuration Cloudflare imparfaite, WordPress doit continuer à résister.
Le durcissement WordPress se joue à plusieurs niveaux: mises à jour, réduction des plugins, configuration des rôles, gestion de l’authentification. Les plugins de sécurité peuvent apporter des fonctions intéressantes (limitation, durcissement des formulaires), mais ils peuvent aussi être redondants avec Cloudflare. La redondance est utile jusqu’au point où elle devient un conflit.
Checklist WordPress, orientée configuration du trafic
Pour compléter Cloudflare, voici une liste courte, orientée sur les risques qui se manifestent le plus souvent.
- Mettre à jour WordPress, thèmes et plugins, et supprimer ce qui n’est pas utilisé. Désactiver ou limiter l’accès à xmlrpc.php si vous n’en avez pas besoin. Renforcer la page de connexion avec limitation des essais et verrouillage temporaire côté application. Vérifier la configuration des rôles utilisateurs, surtout pour les comptes admins et editor. Contrôler les logs d’authentification, repérer les patterns anormaux et agir sur les règles.
Cette checklist n’est pas un remplacement de Cloudflare. C’est un filet. Un incident vient souvent d’une combinaison d’erreurs. Si une règle Cloudflare n’est pas appliquée comme prévu, WordPress doit quand même ralentir et refuser.
Les interactions qui causent des “faux positifs”
Un des points les plus frustrants en sécurité, ce sont les blocages qui semblent logiques mais qui cassent votre site, ou qui bloquent les bons utilisateurs.
Les interactions typiques:
- Un plugin de sécurité WordPress qui ajoute des règles de blocage basées sur des headers différents de ceux utilisés par Cloudflare. Un système de cache côté WordPress ou un plugin “cache” qui ne respecte pas les exclusions de pages d’authentification. Un formulaire de contact ou un plugin e-commerce qui envoie des requêtes AJAX avec des paramètres inattendus, ce qui déclenche un WAF. Une règle géographique qui bloque des pays légitimes, parce que votre audience a changé ou que vos campagnes marketing ont évolué.
Le remède n’est pas seulement “désactiver la règle”. C’est de comprendre ce que le trafic fait vraiment. Regardez les requêtes exactes dans les logs, comparez au comportement attendu, puis réduisez l’impact.
Un exemple concret: sur un site avec un plugin de réservation, un WAF trop strict a bloqué des requêtes portant des paramètres qui ressemblaient à des injections. Les logs montraient des 403, mais sur le front, la réservation échouait sans message clair. On a résolu en ciblant le WAF sur des patterns plus précis au lieu de bloquer large. Résultat: moins de blocages inutiles, et le site est redevenu fiable.
Réglages d’en-têtes, IP réelle, et sécurité “logique”
Un élément sous-estimé est l’en-tête “IP client” (et plus largement les en-têtes liés à la terminaison SSL et au protocole). Si WordPress ou un plugin s’appuie sur une méthode d’identification de l’utilisateur, mais que l’IP réelle n’est pas correctement renseignée, vous perdez la capacité à:
- calculer des taux cohérents, appliquer des blocages par IP, analyser l’activité suspecte.
La conséquence peut être silencieuse. Tout “fonctionne”, puis un jour vous constatez que les blocages ne s’appliquent pas comme prévu. Ou bien vous n’arrivez pas à corréler un incident avec une source précise.
La bonne pratique consiste à valider, après configuration Cloudflare, que votre application voit bien le bon protocole (https) et la bonne IP cliente. Cette validation passe par des tests et, souvent, par la configuration de votre hébergeur ou de votre environnement serveur. Si votre serveur est en Nginx ou Apache avec des proxies, il faut que les paramètres de proxy soient corrects. Sur WordPress, les plugins de sécurité peuvent aussi avoir leurs propres options “behind a proxy”, “real IP”, ou “Cloudflare”.
Ce que je ferais en premier sur un site existant
Si vous reprenez un site déjà en production, l’ordre des actions compte. J’essaie de minimiser le risque de casse.
Je commence par vérifier l’état actuel:
- quelles URLs reçoivent le plus de tentatives, si wp-login.php et xmlrpc.php sont ciblés, si les erreurs 403 ou 429 ont déjà commencé à apparaître, et si l’IP source est correcte dans les logs.
Ensuite, je fais un premier lot de changements simples: HTTPS, redirections, ajustements WAF/règles dans un mode prudent, et activation du proxy sur les enregistrements nécessaires.
Une fois les fondamentaux stables, je passe à l’optimisation des règles: rate limiting ciblé, défis sur patterns anormaux, et éventuellement des règles de contournement pour des endpoints utilisés par vos plugins (par exemple un endpoint de recherche ou de chargement dynamique). Je préfère une progression en étages, plutôt qu’un “tout d’un coup”.
Maintenir la sécurité sur la durée, sans épuiser l’exploitation
La sécurité n’est pas un réglage unique, c’est un processus. Cloudflare et WordPress évolueront, et les menaces aussi.
Deux bonnes habitudes font gagner du temps:
- Revoir régulièrement les règles et les exceptions. Une exception qui date de six mois peut devenir un trou si un plugin a changé. Suivre les tendances, pas les pics isolés. Un scan unique n’est pas un incident. Un changement de pattern persistant, oui.
Enfin, la documentation interne est cruciale. Quand vous appliquez une règle Cloudflare qui explique une limitation de trafic, notez pourquoi elle existe, sur quel endpoint, et quels tests ont été faits. Dans les petites équipes, ce détail évite des “déblocages” involontaires.
Points d’attention spécifiques selon votre contexte
Tous les sites WordPress ne se comportent pas pareil. Quelques scénarios méritent un ajustement fin.
Un site multilingue peut avoir des caches et des redirections supplémentaires, certains plugins ajoutent des endpoints en ajax, et des pages privées peuvent dépendre de cookies. Un site e-commerce peut déclencher des comportements de panier, de checkout et de pré-remplissage de formulaires. C’est là que la tentation de bloquer “tout ce qui ressemble à une requête non standard” devient dangereuse.
Si vous utilisez un système de paiement externe, attention à ce qui est bloqué ou challenge. Les callbacks doivent rester fiables. Une règle qui challenge une requête d’un service externe peut être catastrophique, car elle échoue parfois seulement, en fonction de latence ou de réessais.
Le bon réflexe, c’est de ne pas appliquer des règles “au nom de la sécurité” sur des routes qui servent des intégrations. Quand il faut décider, regardez les requêtes réelles. Les règles doivent refléter votre usage, pas un modèle générique.
Évaluer l’impact: comment savoir si ça marche
On ne sécurise pas uniquement pour “se sentir protégé”. On sécurise pour réduire les incidents et améliorer la stabilité.
Les indicateurs que je surveille le plus:
- la baisse des tentatives sur wp-login.php et xmlrpc.php, la diminution des erreurs liées à des requêtes malformées, la stabilité des pages sensibles (moins de 403 et moins de 5xx), et la capacité à conserver des connexions fiables pour les utilisateurs légitimes.
Si vous voyez une baisse du bruit et un site plus stable, c’est généralement un bon signe. Si vous voyez des plaintes utilisateurs, des erreurs intermittentes, ou des pages qui chargent mal, c’est un signal d’incompatibilité. Dans ce cas, vous revenez à la règle précise, pas à l’ensemble du dispositif.
Une approche “défense en profondeur” qui reste utilisable
La tentation, en sécurité WordPress, c’est de vouloir tout verrouiller, partout, tout le temps. Le problème, c’est que les sites sont des systèmes vivants, avec des plugins, des intégrations et des comportements dynamiques. Les règles trop strictes finissent par générer plus de friction que de protection.
Cloudflare et WordPress fonctionnent mieux ensemble quand vous traitez la sécurité comme un ensemble cohérent:
- Cloudflare filtre et réduit le bruit, WordPress protège la logique d’authentification et la surface applicative, et vous ajustez au fil des logs, en restant pragmatique.
C’est cette cohérence qui transforme la sécurité WordPress d’un dossier abstrait en un dispositif concret. Une fois que le trafic malveillant est ralenti au bon endroit, vous retrouvez des logs lisibles, des temps de réponse plus stables, et une exploitation plus sereine.