WordPress propulse plus de 40 % du web, ce qui en fait le CMS le plus ciblé par les bots automatisés, les script kiddies et les attaquants sophistiqués. Chaque site WordPress non protégé subit des milliers de requêtes malveillantes quotidiennement — tentatives de connexion par force brute, attaques d’amplification XML-RPC, sondes d’injection SQL et scans de traversée de répertoires. Le pare-feu applicatif web (WAF) de Cloudflare fournit une puissante couche de défense gratuite qui bloque ces attaques en périphérie, avant même qu’elles n’atteignent votre serveur. Dans ce guide, vous allez configurer des règles WAF personnalisées qui bloquent les vecteurs d’attaque WordPress les plus courants.

Prérequis

  • Un compte Cloudflare (le plan gratuit fonctionne pour un maximum de 5 règles personnalisées)
  • Le DNS de votre domaine géré par Cloudflare (proxy orange-cloud activé)
  • Une installation WordPress fonctionnelle
  • Un accès administrateur au tableau de bord Cloudflare
  • Votre adresse IP publique actuelle (pour autoriser l’accès admin)

Pourquoi WordPress a besoin d’une protection WAF

Les sites WordPress font face à un barrage incessant d’attaques automatisées. Selon les données de Wordfence, un site WordPress typique subit plus de 90 000 tentatives de connexion malveillantes par mois. Les points d’accès les plus exploités sont :

  • xmlrpc.php — utilisé pour l’amplification de force brute (une seule requête peut tester des centaines de mots de passe), les abus de pingback pour des attaques DDoS et les attaques SSRF
  • wp-login.php — ciblé par les bots de bourrage d’identifiants utilisant des listes de mots de passe divulgués
  • wp-admin/ — sondé pour un accès non authentifié aux fonctions d’administration
  • wp-json/wp/v2/ — l’énumération de l’API REST expose les noms d’utilisateurs et la structure du contenu
  • Chaînes de requête — tentatives d’injection SQL via ?id=1 UNION SELECT, traversée de chemin via ../../etc/passwd

Un pare-feu au niveau serveur comme iptables ne voit que les adresses IP. Le WAF Cloudflare inspecte les requêtes HTTP à la couche 7 — il peut analyser les chemins URI, les chaînes de requête, les en-têtes, les méthodes de requête et les agents utilisateurs. Cela vous permet d’écrire des règles précises qui bloquent les attaques sans affecter les visiteurs légitimes.

Règles WAF essentielles

Accédez à votre tableau de bord Cloudflare : Security > WAF > Custom rules. Vous allez créer ces règles par ordre de priorité.

Règle 1 : Bloquer xmlrpc.php

C’est la règle la plus impactante. xmlrpc.php représente la majorité du trafic de force brute sur la plupart des sites WordPress.

Expression:
(http.request.uri.path eq "/xmlrpc.php")

Action: Block

Si vous dépendez de Jetpack ou de l’application mobile WordPress, changez l’action en Managed Challenge au lieu de Block. Mais si vous pouvez désactiver complètement xmlrpc, bloquez-le.

Règle 2 : Questionner wp-login.php

Plutôt que de bloquer directement la page de connexion, utilisez un défi géré pour que les administrateurs légitimes puissent toujours passer tandis que les bots sont arrêtés.

Expression:
(http.request.uri.path eq "/wp-login.php")

Action: Managed Challenge

Cela force le défi intelligent de Cloudflare (CAPTCHA ou défi JS) sur chaque requête vers la page de connexion. Les bots automatisés échouent au défi ; les vrais humains le passent de manière transparente.

Règle 3 : Restreindre wp-admin par IP

Verrouillez la zone d’administration à votre adresse IP. Le détail crucial ici est l’exclusion de admin-ajax.php, que WordPress utilise pour les appels AJAX frontend (formulaires de contact, mises à jour du panier WooCommerce, etc.).

Expression:
(http.request.uri.path contains "/wp-admin"
  and not http.request.uri.path contains "admin-ajax.php"
  and not ip.src in {203.0.113.50})

Action: Block

Remplacez 203.0.113.50 par votre IP réelle. Vous pouvez ajouter plusieurs IP en utilisant une liste : {203.0.113.50 198.51.100.25}.

Règle 4 : Bloquer les injections SQL et la traversée de chemins

Détectez les schémas d’injection courants dans l’URI complète, y compris les chaînes de requête.

Expression:
(http.request.uri contains "union select"
  or http.request.uri contains "concat("
  or http.request.uri contains "../"
  or http.request.uri contains "eval("
  or http.request.uri contains "<script"
  or http.request.uri contains "etc/passwd")

Action: Block

Cette règle capture les payloads SQLi et XSS les plus fréquents. Les schémas couvrent l’injection basée sur UNION, la traversée de chemins, l’injection JavaScript et les tentatives d’inclusion de fichiers locaux.

Règle 5 : Bloquer les agents utilisateurs malveillants

De nombreux outils d’attaque utilisent des agents utilisateurs identifiables. Combinez le blocage de bots dans une seule règle pour économiser vos créneaux de règles du plan gratuit.

Expression:
(http.request.uri.path contains "/wp-"
  and (http.user_agent contains "sqlmap"
    or http.user_agent contains "nikto"
    or http.user_agent contains "wpscan"
    or http.user_agent contains "masscan"
    or http.user_agent eq ""))

Action: Block

Les agents utilisateurs vides sur les points d’accès WordPress sont presque toujours des scanners malveillants. Cette règle les bloque en même temps que les signatures d’outils d’attaque connus.

Fonctionnalités WAF : Gratuit vs Pro vs Business

FonctionnalitéGratuitPro (20 $/mois)Business (200 $/mois)
Règles WAF personnalisées520100
Ensembles de règles gérées (OWASP)NonOuiOui
Règles de limitation de débit11050
Gestion des botsBasiqueAmélioréeAvancée
Pages d’erreur personnaliséesNonOuiOui
Analytique WAFÉvénements basiquesDétailléeComplète avec journaux
Règles d’accès IPIllimitéesIllimitéesIllimitées
Modification des en-têtes de réponseNonOuiOui

Pour la plupart des sites WordPress, le plan gratuit avec 5 règles personnalisées bien conçues couvre 90 % du trafic d’attaque. Passez au plan Pro si vous avez besoin des ensembles de règles gérées OWASP ou de plus de créneaux de règles.

Scénario concret

Vous gérez un site e-commerce WordPress sur WooCommerce qui traite 500 commandes par jour. Vos journaux serveur montrent plus de 1 200 tentatives de connexion échouées par jour sur wp-login.php, votre xmlrpc.php est bombardé 8 000 fois par jour par des botnets, et vous avez remarqué des chaînes d’injection SQL dans vos journaux de requêtes. Votre hébergeur vous avertit des pics de CPU causés par le traitement de toutes ces requêtes malveillantes.

Après avoir activé les cinq règles WAF ci-dessus, Cloudflare bloque 95 % de ce trafic en périphérie. L’utilisation CPU de votre serveur chute de 40 %, les temps de chargement des pages s’améliorent car vos workers PHP ne sont plus occupés à traiter les requêtes d’attaque, et vos coûts d’hébergement restent stables au lieu d’augmenter. Le défi géré sur wp-login.php stoppe le bourrage d’identifiants tandis que votre équipe éditoriale se connecte sans problème. La restriction IP de wp-admin signifie que même si un attaquant obtient les identifiants, il ne peut pas accéder au tableau de bord depuis son IP.

Limitation de débit pour WordPress

La limitation de débit ajoute une dimension temporelle à votre protection. Accédez à Security > WAF > Rate limiting rules.

Limitation de débit sur la page de connexion

Expression:
(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")

Rate: 5 requests per 10 seconds
Action: Block for 600 seconds (10 minutes)
Counting expression: Same as rule expression

Limitation de débit sur l’API REST

Expression:
(http.request.uri.path contains "/wp-json/")

Rate: 30 requests per 10 seconds
Action: Managed Challenge

Cela empêche l’énumération et l’abus de l’API tout en permettant l’utilisation normale de l’API REST par les thèmes et les extensions.

Résolution de Problèmes

admin-ajax.php doit être exclu — WordPress utilise admin-ajax.php pour les requêtes AJAX frontend même pour les visiteurs non connectés. Les formulaires de contact, l’ajout au panier WooCommerce et le défilement infini utilisent tous ce point d’accès. Le bloquer derrière une restriction IP casse tout votre frontend.

API REST WooCommerce — si vous utilisez l’API REST WooCommerce pour des intégrations externes (fournisseurs d’expédition, synchronisation de stock, systèmes de point de vente), assurez-vous que votre limitation de débit sur /wp-json/ ne bloque pas ces services. Ajoutez leurs IP en liste blanche ou utilisez un seuil plus élevé.

Cron et tâches planifiées — wp-cron.php est sollicité par les pages mises en cache Cloudflare. Si vous utilisez un cron côté serveur (recommandé), vous pouvez bloquer l’accès externe à wp-cron.php dans une règle WAF.

Mises à jour de plugins et téléversement de fichiers — certains plugins font des requêtes vers les chemins wp-admin lors des mises à jour automatiques. Votre règle de restriction IP gère cela tant que le serveur lui-même n’est pas relayé via un service externe qui change l’IP source.

Prudence avec le blocage par pays — évitez de bloquer des pays entiers sauf si vous n’avez vraiment aucun utilisateur là-bas. Les blocages au niveau des pays peuvent par inadvertance bloquer les robots d’indexation des moteurs de recherche qui transitent par ces pays, impactant votre SEO.

Testez minutieusement — après avoir activé les règles, ouvrez une fenêtre de navigation privée et testez : visitez la page d’accueil, naviguez vers une page produit, soumettez un formulaire de contact et connectez-vous à wp-admin. Vérifiez Security > Events pour tout faux positif.

Résumé

  • Bloquez complètement xmlrpc.php — c’est le point d’accès WordPress le plus exploité et la plupart des sites n’en ont pas besoin
  • Utilisez les défis gérés sur wp-login.php pour stopper les bots tout en laissant passer les administrateurs humains
  • Restreignez wp-admin par IP mais excluez toujours admin-ajax.php pour éviter de casser les fonctionnalités frontend
  • Ajoutez la détection de schémas d’injection SQL et XSS pour capturer les payloads d’injection courants en périphérie
  • Configurez la limitation de débit sur les points d’accès de connexion et de l’API REST pour limiter les tentatives de force brute
  • Le plan gratuit de Cloudflare vous donne 5 règles personnalisées — suffisant pour couvrir la surface d’attaque WordPress critique
  • Surveillez les événements de sécurité après le déploiement des règles et ajustez en cas de faux positifs
  • Envisagez Cloudflare Access (Zero Trust) pour les scénarios d’IP dynamiques au lieu de la liste blanche par IP

Articles Connexes