WAF, CDN et anti-bots : filtrer le mauvais trafic avant qu’il n’atteigne WordPress

Tu as l’impression de courir après des ralentissements, des pics CPU ou des tentatives de connexion en rafale ? La vérité, c’est que 40 à 70 % du trafic qui frappe un WordPress n’a rien d’humain. Entre scraping agressif, brute force, bots de mauvaise qualité et attaques par DDoS WordPress, tu finis par payer en performance, en sécurité et en facture serveur. La bonne nouvelle : en plaçant un firewall applicatif WordPress à l’edge (un sécurité WordPress WAF) et un CDN WordPress avec protection anti-bot WordPress, tu peux filtrer l’essentiel du bruit avant même que PHP ne s’allume. Résultat : moins de charge, un TTFB stable, et un back-office plus réactif.

Dans cet article, on compare les options WAF/CDN, on clarifie ce qui bloque quoi, puis on te propose une configuration type prête à l’emploi. On parlera aussi d’équilibre : bloquer ce qui dérange sans gêner Googlebot, Stripe, ou tes clients WooCommerce. WP Builders met en place ce genre d’architecture tous les jours : notre but est que tu comprennes les leviers, que tu les testes, et que tu gagnes en sérénité.

Pourquoi filtrer en amont : l’effet levier du WAF/CDN

WordPress est performant quand on l’utilise pour servir des pages, pas pour encaisser des vagues de requêtes inutiles. Filtrer en amont agit avant PHP et MySQL :

• Réduction de charge : moins de requêtes atteignent le serveur, surtout sur /wp-login.php, /xmlrpc.php et l’API REST.
• Performance durable : un CDN met en cache et sert les assets statiques depuis des PoP proches de l’utilisateur.
• Résilience DDoS : les réseaux distribués absorbent les rafales volumétriques.
• Surface d’attaque réduite : IPs malveillantes bloquées, signatures d’exploits détectées, anomalies de comportement challengées.

Le vrai changement de paradigme : on ne joue plus uniquement avec des plugins côté WordPress, on déporte le tri à la frontière du réseau, là où les paquets arrivent.

WAF, CDN et anti-bots : qui fait quoi ?

CDN : accélérer et décharger

Un CDN WordPress sert les contenus statiques (images, CSS, JS) depuis des serveurs proches de l’utilisateur. Certains CDN peuvent aussi mettre en cache des pages HTML pour les visiteurs anonymes. Le CDN ne remplace pas un WAF, mais beaucoup l’intègrent nativement.

WAF : firewall applicatif WordPress

Le WAF inspecte les requêtes HTTP et bloque ce qui ressemble à une attaque : injections SQL/XSS, patterns d’exploitation, scanners. Idéalement placé à l’edge, il agit avant que la requête n’atteigne ton origine. Pour les bases, la définition de l’OWASP reste une référence : qu’est-ce qu’un WAF et comment il protège une application web.

Anti-bots : comportement plutôt que signature

Les protections anti-bot modernes combinent signaux de réputation IP, empreintes navigateur, défis JavaScript, modèles comportementaux, et parfois machine learning. L’idée n’est pas d’interdire tous les bots, mais d’arrêter ceux qui créent de la charge (scraping agressif, brute force, achats automatisés). Pour creuser, regarde la doc Cloudflare sur la gestion des bots : Bot Management et Super Bot Fight Mode.

Plugin WAF vs WAF à l’edge

Un plugin de sécurité côté WordPress peut bloquer des attaques, mais il est servi après que PHP/WordPress se soit déjà chargé, donc il consomme des ressources. Un WAF/CDN à l’edge filtre avant d’atteindre le serveur. Dans la majorité des cas, on recommande edge en priorité, et un plugin léger pour compléter (audit, 2FA, durcissement).

Panorama des solutions WAF/CDN pour WordPress

Voici les grandes familles que l’on déploie le plus souvent chez WP Builders, avec leurs points forts :

Cloudflare (Free/Pro/Business)

• Points forts : DNS géré, proxy, cache, WAF managé, JS challenge, modes anti-bots, règles faciles, page rules, Workers, images, CDN mondial.
• Pour qui : de la TPE au grand compte. Le plan Pro suffit souvent pour un site vitrine/lead.
• À noter : bien configurer le cache HTML pour WordPress et exclure les sessions/admin.

Sucuri

• Points forts : WAF/anti-DDoS, nettoyage malware, CDN, support réactif. Intéressant pour sites déjà compromis.
• Pour qui : e-commerces et sites sensibles qui veulent un service all-in-one.

Akamai / Fastly

• Points forts : performances très élevées, règles fines, excellents PoP. Adaptés aux sites à fort trafic et exigences SLA.
• Pour qui : entreprises, médias, marketplaces.

AWS CloudFront + AWS WAF

• Points forts : écosystème AWS, règles personnalisées, intégration Lambda@Edge.
• Pour qui : équipes techniques familières d’AWS.

Le choix dépend de ton volume, de tes compétences internes et de ton budget. L’important : opter pour une solution avec WAF managé + règles personnalisables + anti-bots comportemental + journalisation.

Configuration type : 90 % du résultat en 60 minutes

Voici une trame simple que nous utilisons souvent en mission. Elle s’applique très bien à Cloudflare, mais l’idée est similaire ailleurs.

1. Passer le DNS en proxy (orange cloud) : tout le trafic passe par le CDN/WAF. Ne proxifie pas d’emblée le mail, les sous-domaines API tiers, ou les entrées qui n’ont pas besoin d’edge.
2. Activer le WAF managé : règles par défaut, sensibilité “Medium/High”, activer les corpus pour WordPress/PHP si disponibles.
3. Réglage du cache : cache statique actif, respect des headers d’origine, et règle de page “Cache everything” pour les pages publiques (hors admin/checkout). Définir un bypass par cookie de session (wordpress_logged_in_, woocommerce_items_in_cart).
4. Rate limiting ciblé : limiter à 10-20 req/min/ IP sur /wp-login.php, /xmlrpc.php, et éventuellement /wp-json/wp/v2/* si abus. Réponse 429 ou challenge.
5. Firewall rules “challenge-first” :
   • Si chemin = /wp-login.php ET pays ≠ cible → JS Challenge.
   • Si agent = vide ou bibliothèques connues de scraping agressif → Challenge.
   • Si requêtes POST répétées en peu de temps → Challenge/Block.
6. Anti-bots : activer le mode anti-bots ou Bot Management si disponible. Autoriser explicitement Googlebot/Bingbot via vérification de reverse DNS pour éviter les faux positifs.
7. Protéger l’API : si tu n’utilises pas l’API REST publiquement, restreins /wp-json/ aux IPs ou tokens nécessaires (apps, webhook). Sinon, challenge pour les anonymes sur les endpoints sensibles.
8. Désactiver/limiter XML-RPC : si inutile, bloque /xmlrpc.php. Si tu relies Jetpack ou apps mobiles, limite par IP source.
9. Hardening de l’origine : refuser le trafic direct non issu du CDN (firewall serveur avec allowlist des IP du CDN), forcer HTTPS, HTTP/2/3, HSTS, et désactiver index of.
10. Observabilité : activer les logs WAF/bots, exporter vers un SIEM ou au minimum analyser chaque semaine. Mettre en place un monitoring externe pour la dispo et le TTFB.

Règles concrètes : ce qui bloque sans casser

Voici des modèles de règles que nous adaptons souvent (à traduire dans le format de ton fournisseur) :

• /wp-login.php : Challenge par défaut pour les IP hors pays de ta clientèle. Si échec ou trop de tentatives, Block 24 h. Autoriser en allowlist tes IP d’administration.
• /xmlrpc.php : Block global si non utilisé. Sinon Rate limit 5 req/10 s + allowlist des IPs Jetpack.
• /wp-admin/ : Bypass cache + Require cookie de session + Challenge pour les anonymes.
• API REST : Challenge les POST anonymes, throttle les GET massifs (>60 req/min) sur /wp-json/wp/v2/posts.
• WooCommerce : ne pas cacher /checkout ni /my-account. Appliquer Rate limit doux sur ?add-to-cart pour éviter le scraping prix.
• Bad UA / No UA : Challenge ou Block selon fréquence. Les véritables bots moteurs ont un reverse DNS vérifiable.
• Géorestriction : si ton business est local, n’hésite pas à challenger le reste du monde sur les endpoints sensibles.

Astuce : commence en “Challenge” plutôt qu’en “Block”. Tu réduis la charge immédiatement tout en limitant les faux positifs. Observe 48 h, puis durcis sur les patterns manifestement malveillants.

Stoppe les bots avant qu’ils n’éteignent ton site

Audit express WAF/CDN + mise en place de règles efficaces en moins de 48 h. Résultats mesurables sur la charge et la sécurité.

Protéger mon WordPress maintenant

Performance et DDoS : ne sacrifie pas la rapidité

Un WAF/CDN bien réglé rend le site plus rapide, pas l’inverse. Points clés :

• Cache HIT : surveille le taux de HIT sur les pages publiques. Chaque MISS inutile coûte du CPU.
• Bypass intelligent : identifie précisément ce qui ne doit pas être caché (admin, panier, compte) et mets tout le reste en cache.
• DDoS WordPress : active la protection L3/L4/L7. Les attaques d’application (L7) se reconnaissent à un afflux de GET/POST sur des URLs coûteuses (recherches, endpoint d’API).
• HTTP/2 et HTTP/3 : meilleurs temps de chargement, multiplexing, moins de connexions.

Suivi et preuves d’impact

Ne pilote que ce que tu mesures :

• Logs WAF/Bot : nombre de requêtes bloquées, pays, UA, endpoints. Cherche les pics et corrèle avec CPU/TTFB.
• Serveur : charge CPU, workers PHP, connexions, I/O disque, RAM. Avant/après déploiement.
• Frontend : TTFB, LCP, INP. Observe la stabilité, pas seulement la moyenne.
• Business : conversions et taux d’erreur checkout. Un bon filtrage ne doit pas impacter les ventes.

Erreurs classiques à éviter

• Bloquer trop : surprotéger l’admin et l’API sans allowlist peut gêner tes webhooks (Stripe, PayPal, CRM). Teste les scénarios critiques.
• Cache mal ciblé : mettre en cache le panier ou les comptes provoque des fuites de session. Utilise le bypass par cookie.
• Oublier le trafic direct : si ton serveur accepte encore le trafic direct, les attaquants contournent l’edge. Ferme l’origine aux IPs du CDN.
• Ignorer les bots légitimes : Googlebot/Bingbot doivent être explicitement autorisés via reverse DNS.
• Ne pas itérer : les menaces évoluent. Revois tes règles chaque mois, au minimum après un pic d’attaque.

Durcir WordPress sans le ralentir

Le duo gagnant : filtrer à l’edge, durcir à l’origine. Quelques réglages rapides côté serveur et WordPress :

• Limiter les tentatives de connexion côté edge + 2FA dans WordPress pour les comptes admin.
• Désactiver XML-RPC si inutile. À défaut, restreindre par IP.
• Masquer la version de WordPress et restreindre l’exploration de /wp-content.
• Mises à jour cœur/plugins/thèmes + surveillance vulnérabilités.
• Backups réguliers hors-serveur et tests de restauration.

Checklist de déploiement express (30 minutes)

1. Basculer le DNS en proxy sur le CDN avec WAF.
2. Activer le WAF managé (profil WordPress/PHP).
3. Mettre en cache “Everything” pour les visiteurs anonymes avec bypass par cookie.
4. Créer des règles de challenge pour /wp-login.php, /xmlrpc.php, /wp-json/.
5. Appliquer le rate limiting sur login, XML-RPC, API REST.
6. Autoriser explicitement Googlebot/Bingbot (reverse DNS).
7. Fermer l’origine aux IPs du CDN uniquement.
8. Tester scénarios : connexion admin, checkout WooCommerce, webhooks.
9. Monitorer CPU/TTFB/logs pendant 48 h, ajuster.
10. Documenter et planifier une revue mensuelle des règles.

Quand faire appel à un pro ?

Si tu vois des symptômes récurrents (pics CPU, erreurs 502/504, admin impraticable, crawling sauvage), c’est qu’il faut aller plus loin : corrélation des logs, ajustement fin des règles, et parfois un découplage CDN/cache avancé. C’est précisément le métier de WP Builders : on intervient vite, on stabilise, puis on te laisse avec une configuration claire et documentée, adaptée à ton business.

Tu veux garder la main mais gagner du temps ? On peut aussi te créer un socle prêt à l’emploi que tu sauras faire évoluer. L’objectif : un WordPress rapide et serein, même sous pression.