WAF / Cloudflare : utile ou théâtre ? Je les utilise. Je ne les vends pas comme une sécu. Cloudflare apporte CDN, DDoS, règles, parfois un cache de page (attention tunnel). Un WAF bloque des patterns. Ni l'un ni l'autre ne remplace la double authentification, les mises à jour et un nombre réduit d'administrateurs. Cet article dit ce que je configure, ce que je refuse (proxy Cloudflare (nuage orange) + cache agressif sur Woo), et comment savoir si vous avez acheté du calme ou du théâtre.
🛡️ Utile : quand le socle existe
Cacher l'origine, absorber un flood, règles sur `/wp-login.php`, cache des assets, HTTP/3. Sur une vitrine tenue, c'est du confort et un peu de sécu. Je dis oui.
Théâtre : « on a mis Cloudflare » et des admins `admin/admin`, XML-RPC ouvert, maj de 18 mois. Le WAF devient un rideau.
🧊 Cache Cloudflare vs tunnel
Cache « everything » sur une boutique : (voir l'article sur le cache et le tunnel de commande). Les cookies WooCommerce + HTML figé = panier fantôme. On exclut, ou on ne cache que les fichiers statiques.
Les règles trop agressives cassent Gutenberg, l'admin, les webhooks (Stripe). On teste l'admin et le webhook après.
- Origine non publique si possible
- Pas de cache HTML sur le tunnel
- Règles login, pas 80 règles illisibles
- SSL full (strict) compris
🎭 Comment détecter le théâtre
Aucun log regardé, règles par défaut, cache de tout le site, prestataire qui dit « vous êtes protégés » sans 2FA. Utile : quelques règles écrites, un runbook, le socle à jour.
WAF / Cloudflare utile ou théâtre : je m'en sers comme d'un outil. Pas comme d'un contrat de sécu.
📊 Lire ce que le pare-feu bloque
Un WAF utile se regarde. Une fois par mois, j'ouvre les événements : quelles règles déclenchent, sur quelles adresses, depuis où. Une règle qui ne bloque jamais rien est inutile. Une règle qui bloque vos clients est pire.
Si les attaques visent toujours `/wp-login.php`, c'est un signal : le login est exposé, la 2FA doit être en place. Le pare-feu montre où frapper, il ne remplace pas le travail sur le site.
✅ Liste de contrôle avant de brancher le pare-feu
Avant de brancher le pare-feu, j'écris ce qui vise vraiment le site : connexions répétées sur wp-login, robots qui aspirent le catalogue, pics de trafic. La mesure qui compte : les journaux du serveur avant et après, pas le compteur de menaces affiché par l'outil.
Sauvegarde restaurable, accès DNS à votre nom, 2FA (double authentification) sur le compte Cloudflare. Puis le branchement et les règles. Puis 24 à 72 h de lecture des requêtes bloquées. Sans cette lecture, le pare-feu est allumé, rien ne prouve qu'il laisse passer les bons visiteurs.
- Journaux d'accès relevés sur une journée normale
- Copie de test avant de brancher le pare-feu
- Un changement à la fois, documenté
- Test du paiement, du formulaire et de l'admin après chaque règle, puis 24 à 72 h de suivi des blocages
📌 Ce que je refuse sur ce sujet
Je refuse de présenter un pare-feu comme une protection pour un site jamais mis à jour. Je refuse aussi les règles copiées d'un tutoriel sans test : elles finissent par bloquer le paiement ou les robots de Google.
Quand le vrai risque est une extension abandonnée ou un mot de passe partagé, c'est par là que je commence, pas par un abonnement de sécurité.
Un WAF sans logs lus, c'est un sticker sur la porte.
🧭 Questions fréquentes
Faut-il le mettre en place tout de suite ? Oui si le site subit des attaques répétées, des robots qui saturent le serveur ou des tentatives de connexion en masse. Sinon, on le planifie avec les réglages DNS, pas un soir de panique.
Peut-on le brancher sans test ? Rarement : un pare-feu mal réglé bloque aussi vos clients, vos paiements ou votre propre accès. Voir Tester un site WordPress en local et en préprod pour essayer les règles hors production.
Combien de temps ? Une demi-journée pour un branchement simple, plusieurs jours pour affiner les règles sur une boutique. Un devis « on met Cloudflare, vous êtes protégé » ne parle jamais des faux positifs.
