Quand un site WordPress est exposé directement à Internet, une grande partie des risques ressemble à une mécanique répétitive: des tentatives de connexion automatisées, des scans de versions, des requêtes qui chargent inutilement le serveur, et parfois des attaques qui cherchent juste un point faible évident (un formulaire mal protégé, un plugin obsolète, une page d’administration trop devinable). Mettre Cloudflare devant WordPress ne “magiquement” stoppe pas tout, mais ça change la dynamique. Vous réduisez la surface d’exposition, vous ajoutez un pare-feu applicatif, et vous pouvez pousser la plupart des requêtes vers une couche qui absorbe mieux le volume.
Ce qui suit est un exemple concret de configuration, pensée pour un site WordPress classique, avec un hébergement mutualisé ou VPS, et un besoin de sécurité sans casser le site. L’objectif n’est pas de cocher toutes les options, c’est de choisir celles qui apportent un vrai gain et de comprendre ce que vous acceptez comme compromis.
Ce que Cloudflare apporte vraiment à WordPress
Cloudflare se place entre les visiteurs et votre serveur WordPress. À partir de là, plusieurs leviers deviennent disponibles.
D’abord, le chiffrement et la terminaison SSL. Vous pouvez imposer HTTPS et éviter certaines erreurs de configuration côté serveur. Ensuite, la protection réseau et applicative: filtrage de requêtes suspectes, règles de pare-feu, limites de débit, challenges anti-bot. Enfin, l’optimisation de distribution via le cache. Même si la sécurité est le sujet, le cache a un effet indirect important: moins de requêtes atteignent PHP, donc moins de points d’attaque “vivants” et moins de ressources consommées.
J’insiste sur un point, souvent mal compris lors des premiers réglages: Cloudflare ne remplace pas la discipline WordPress. Les plugins doivent être maintenus, les thèmes aussi, et l’accès administrateur doit rester strict. Cloudflare complète, il ne fait pas le travail à votre place.
Préparer le terrain avant de toucher au DNS
Avant même d’entrer dans le panneau Cloudflare, j’ai pris l’habitude de faire trois vérifications simples, car elles évitent des heures de diagnostic plus tard.
1) Vérifiez que votre WordPress répond correctement en local réseau, et surtout que les redirections HTTP vers HTTPS sont cohérentes. Si le site renvoie vers une mauvaise URL, la mise en HTTPS derrière Cloudflare amplifie le problème.
2) Vérifiez votre façon d’administrer. Si vous utilisez des adresses IP fixes, du VPN, ou un accès restreint, vous pouvez en tirer parti dans les règles Cloudflare.
3) Vérifiez votre stack “côté serveur”. Si vous avez un CDN interne, un reverse proxy maison, ou un plugin de cache agressif, il faut éviter les conflits de cache et d’entêtes. Cloudflare peut mettre un cache devant, mais si WordPress ou un plugin essaye aussi de “gérer” des choses similaires, les comportements deviennent imprévisibles.
Si vous êtes prêt, l’exemple ci-dessous suppose un domaine déjà opérationnel, avec des DNS actuels vers votre hébergement.
Exemple de configuration Cloudflare pas à pas
Voici le chemin que je suis le plus souvent, dans un ordre qui limite les surprises.
Étapes essentielles
1) Ajoutez votre domaine dans Cloudflare, puis remplacez les serveurs DNS par ceux fournis par Cloudflare. 2) Configurez l’option SSL/TLS et choisissez un mode compatible avec votre serveur (souvent Full ou Full strict selon le certificat côté origine). 3) Ajustez les paramètres https://gardewp.fr/securite-wordpress/ “Firewall” et “WAF” en partant d’un niveau de protection raisonnable. 4) Activez les fonctionnalités “Rate limiting” (limitation de débit) sur les zones à risque, notamment la page de connexion. 5) Testez, observez les logs, puis durcissez progressivement.
Je détaille chaque étape, avec des réglages typiques et ce que j’attends concrètement d’eux.
Mettre les DNS Cloudflare en place sans casser le domaine
Le passage DNS est souvent considéré comme “très simple”, mais c’est aussi le moment où vous pouvez créer une double couche de redirection, des erreurs de certificats, ou des sous-domaines oubliés.
Dans Cloudflare, commencez par déclarer le domaine. Ensuite, remplacez vos serveurs DNS chez votre registraire par ceux Cloudflare. À partir de là, vous devez vérifier que les enregistrements essentiels existent bien: en particulier A/AAAA pour votre site, et éventuellement CNAME pour www.
Un détail pratique: si vous avez un sous-domaine comme blog ou app, décidez tôt s’il passe aussi derrière Cloudflare. Par défaut, Cloudflare se configure par domaine. Les sous-domaines peuvent nécessiter des règles distinctes, notamment pour l’administration.
Une fois la propagation faite, vérifiez que le site sert la bonne page, sans boucle HTTP/HTTPS. C’est à cette étape que je préfère faire des tests simples, plutôt que de lancer toutes les options de sécurité en même temps.
SSL/TLS: choisir un niveau de sécurité compatible
Dans Cloudflare, l’onglet SSL/TLS est souvent le premier endroit où on “monte” la sécurité. Mais il y a un piège classique: Full strict exige un certificat valide sur le serveur d’origine, et il peut refuser si votre hébergement ne présente pas correctement la chaîne.
Pour un exemple réaliste, voici l’approche que je recommande.
- Si votre serveur d’origine gère déjà proprement HTTPS avec un certificat de confiance, vous pouvez viser un mode strict (selon votre contexte). Le bénéfice est une meilleure assurance que la connexion entre Cloudflare et votre origine n’est pas dégradée. Si vous n’êtes pas sûr, utilisez un mode plus permissif pour éviter de rendre le site indisponible. L’objectif n’est pas “tout ou rien” le jour 1.
Une fois le mode choisi, testez: le site charge correctement, les ressources CSS/JS sont bien servies, et la console du navigateur ne montre pas de mélange de contenu (content mixte).
Et surtout: assurez-vous que WordPress, ses plugins, et votre thème ne forcent pas des redirections contradictoires. J’ai déjà vu des cas où Cloudflare forçait HTTPS, tandis que WordPress croyait l’inverse, et cela déclenchait des boucles invisibles pour certains navigateurs, mais pas pour tous.
Activer le pare-feu et le WAF de façon utile, pas décorative
Cloudflare a un WAF et des règles gérées. Le piège, c’est de tout activer à fond et de découvrir ensuite que certains mécanismes de login, certains formulaires, ou des outils de monitoring échouent.
L’approche pragmatique consiste à activer une protection “raisonnable” d’abord, puis à durcir. Vous pouvez aussi utiliser des exclusions ciblées si vous avez des bots légitimes.
Pour WordPress, les zones à surveiller en priorité sont:
- l’accès à wp-login.php et aux tentatives de connexion répétées les endpoints d’API si vous en avez (selon l’usage, XML-RPC peut poser des questions, même si toutes les attaques ne passent pas par là) les requêtes qui ressemblent à du probing de fichiers ou de chemins d’administration
Un exemple concret que j’ai vu souvent: des scans automatiques testent des URLs qui “ressemblent” à WordPress, et même si votre WordPress les répond, le pare-feu réduit les ressources consommées par le serveur en filtrant avant l’application.
Rate limiting: calmer les attaques sans casser les utilisateurs
La limitation de débit est particulièrement efficace contre le bruteforce et les “password sprays”. Elle ne doit pas être un mur trop strict, sinon vous pénalisez les utilisateurs légitimes, par exemple ceux qui ont une connexion instable ou qui testent plusieurs fois un mot de passe.
Dans Cloudflare, je configure en général une règle ciblée sur l’URL de connexion WordPress. Les paramètres exacts dépendent de votre audience et du volume (et de votre tolérance). Sur des sites moyens, je vise typiquement:
- une fenêtre courte (par exemple une minute), un seuil qui laisse passer un utilisateur normal, et qui bloque vite les tentatives répétées.
Le bon réflexe: après activation, surveillez les logs. Si vous voyez des blocs trop fréquents pour des IP d’utilisateurs réels (vous pouvez les identifier dans certains cas), vous assouplissez. Si au contraire vous ne voyez presque aucune activation, vous pouvez parfois ajuster pour gagner en efficacité.
Un conseil issu de la pratique: activez la règle d’abord sans “punition définitive” trop agressive si l’interface vous le permet. L’idéal est de commencer en challenge ou en bloc progressif, selon vos options, puis d’intensifier.
Connexion admin: renforcer sans piéger votre équipe
Protéger la page de connexion WordPress est bien, mais protéger réellement l’accès à votre administration implique plusieurs couches.
Cloudflare peut aider via:
- des règles d’accès basées sur IP (si votre équipe a des IP stables) des challenges pour les tentatives suspectes des contrôles anti-bot
Dans les environnements où j’ai une petite équipe, je privilégie souvent une approche simple: autoriser explicitement les IP de l’équipe à accéder à wp-login.php sans challenge, et appliquer challenge ou rate limiting pour le reste. C’est particulièrement efficace contre les attaques qui n’ont pas d’IP “connues”.
Si votre équipe n’a pas d’IP fixe (travail nomade), vous pouvez toujours garder le rate limiting, puis renforcer avec des challenges uniquement quand un comportement devient anormal.
Ce que je déconseille: des règles trop générales sur toute la partie “login” sans regarder le trafic. Sur certains sites, des plugins de sécurité ou des SSO peuvent déclencher des séquences de requêtes qui ressemblent à des tentatives. Si vous ne contrôlez pas le comportement réel, vous risquez de créer un incident d’accès.
Cache et sécurité: un duo qui se tient, mais avec des limites
Le cache est souvent discuté pour la performance, mais il touche aussi à la sécurité opérationnelle. Moins de requêtes vers PHP, c’est moins d’exécution, donc moins d’opportunités pour des attaques volumétriques et des effets de bord applicatifs.
Dans Cloudflare, activez le cache pour le contenu statique et les pages publiques, et évitez de mettre en cache ce qui ne doit pas l’être (pages d’administration, pages de connexion, parcours avec états).
Un point pratique: certaines configurations de WordPress et certains plugins affichent du contenu dynamique même sur des pages publiques (panier, aperçu, cartouches dynamiques). Dans ce cas, un cache mal réglé peut servir une page incohérente, et vous perdez du temps à “diagnostiquer la sécurité”, alors que le problème est simplement un cache.
Je règle donc mon cache avec prudence, et je teste sur plusieurs navigateurs et plusieurs comptes (au moins un utilisateur connecté, si possible). C’est moins spectaculaire qu’un WAF, mais c’est souvent là que les sites se cassent après une mise en place.
Page règles et exceptions: éviter les effets collatéraux
Cloudflare permet aussi de définir des “Page Rules” ou des réglages par URL selon votre plan. Les règles par URL sont utiles quand vous devez contourner un comportement.
Exemples typiques:
- exclure wp-admin et wp-login.php du cache désactiver certaines optimisations pour un sous-domaine d’administration renforcer un challenge uniquement sur certaines URL sensibles
L’important, c’est de ne pas créer trop d’exceptions “par automatisme”. Chaque exception est une chance d’oublier un cas limite après un changement de plugin.
Observabilité: ce qui change après la mise en place
La sécurité sans visibilité, c’est comme sécuriser un portail sans regarder qui sonne. Cloudflare donne des métriques et des logs. Utilisez-les rapidement après activation.
Quand j’attaque la configuration pour un client, je surveille surtout:
- le nombre de requêtes bloquées ou challengées la proportion de trafic “anormal” vers wp-login.php les erreurs 4xx et 5xx, en gardant en tête que certaines erreurs sont attendues si vous bloquez des bots
S’il y a un pic d’erreurs après un réglage, je reviens un cran et je corrige la logique. Souvent, ce n’est pas l’attaque qui “explose”, c’est une règle trop large ou un paramètre SSL qui ne correspond pas à l’origine.
Cas pratiques: réglages qui évitent les galères
Je partage trois scénarios vécus, avec le raisonnement qui m’a conduit à corriger.
1) Le site charge, mais wp-admin ne marche pas
C’est arrivé lorsque l’origine exigeait un certain mode SSL ou une chaîne de certificat pas parfaitement présentée. En conséquence, Cloudflare pouvait servir le contenu public, mais pas l’administration. Le symptôme apparaissait surtout sur certaines ressources. Le correctif a été de corriger le paramétrage côté origine et de repasser temporairement à un mode plus compatible, puis de remonter ensuite.
2) Trop de challenges sur les connexions
Dans un contexte de formulaire de connexion modifié par un plugin, les requêtes initiales déclenchaient une séquence de comportement que Cloudflare interprétait comme suspect. Résultat: des utilisateurs bloqués ou qui n’avaient pas accès pendant quelques minutes. Le correctif a consisté à ajuster la règle de rate limiting, puis à ajouter une exception plus fine pour les accès légitimes, au lieu d’assouplir toute la protection.
3) Cache et contenu dynamique
Après activation du cache, certaines pages affichaient un contenu “figé”. Ça donnait l’impression d’un problème de sécurité, alors que c’était un problème de cohérence. J’ai ensuite exclu les routes sensibles et confirmé que WordPress envoie les bons en-têtes. Une fois la cohérence rétablie, le WAF a été laissé en l’état.
Checklist de validation (courte, mais utile)
Une fois que tout est activé, faites une vérification rapide. Pas besoin de tout casser, mais il faut confirmer que rien de vital ne s’est dégradé.
- Connexion WordPress testée avec un compte administrateur (depuis une IP “normale” et, si possible, une IP d’équipe) Navigation sur le site public, y compris pages qui ont du contenu dynamique si vous en avez Vérification des redirections HTTP vers HTTPS, sans boucle et sans mélange de contenu Contrôle des logs Cloudflare sur 24 à 48 heures pour repérer les erreurs et les règles trop agressives
C’est ce type d’observation qui transforme un “réglage” en amélioration durable.
Les limites à connaître: ce que Cloudflare ne règle pas
Cloudflare aide beaucoup, mais il y a des limites réalistes.
Un WAF ne remplace pas un WordPress à jour. Les injections exploitent parfois une logique applicative ou une faille de plugin, et la présence d’un pare-feu réseau ne vous évite pas de corriger la cause. De même, la sécurisation des comptes reste centrale: mots de passe forts, MFA si possible, limitation des comptes admin, suppression des comptes inutiles.
Autre limite: une mauvaise configuration peut bloquer des services. Un monitoring, un plugin d’automatisation, une intégration externe, tout cela peut déclencher des patterns. On doit donc garder la main, et vérifier.
Enfin, la sécurité “par le cache” n’est pas une barrière magique contre les attaques. Un attaquant peut viser autre chose que le contenu mis en cache, notamment les endpoints dynamiques et les opérations d’authentification.
Comment durcir ensuite, sans tout risquer
Une fois la base stable, vous pouvez progressivement durcir.
J’ai tendance à avancer par paliers: d’abord stabiliser SSL, ensuite activer une limitation de débit ciblée, puis renforcer le WAF et les challenges quand je vois que le trafic légitime passe sans douleur. Si vous faites tout en une fois, vous ne saurez pas ce qui a causé un problème.
Si vous gérez un site multi-auteurs, pensez aussi à la formation interne. Les meilleures règles Cloudflare ne servent pas si un membre de l’équipe partage le même mot de passe, ou si personne ne sait quoi faire quand une connexion est bloquée.
Conclusion opérationnelle: viser un équilibre
Sécuriser site WordPress avec Cloudflare, ce n’est pas une course au maximum de protection coché. C’est une construction en couches, où l’on gagne d’abord en réduction de surface et en filtrage des comportements évidents, puis on affine pour ne pas pénaliser les utilisateurs légitimes.
Si je devais résumer l’exemple présenté: commencez par une base SSL solide, activez une protection WAF raisonnable, ajoutez du rate limiting ciblé sur wp-login.php, puis contrôlez les logs. Ensuite seulement, durcissez. Ce rythme évite la grande majorité des incidents “je l’ai activé et maintenant ça casse”.
Si vous voulez, dites-moi votre configuration (hébergement, présence de www, mode SSL actuel côté origine, et si vous utilisez un plugin de cache ou de sécurité). Je pourrai vous proposer un exemple de réglages plus précis, adapté à votre cas, sans sur-corriger.