Un WAF (Web Application Firewall) n’est pas un gadget “anti-hack”. Bien configuré, il devient un filtre rationnel devant votre site, qui réduit la surface d’attaque, ralentit les automatisations opportunistes et vous donne des signaux exploitables. Mal configuré, il finit par bloquer vos clients, vos bots utiles (indexation, monitoring) et parfois vos propres formulaires. Le vrai travail consiste donc à trouver le bon niveau de sévérité et à régler le WAF comme on règle un système de sécurité physique, pas comme on change juste un curseur.
Dans le contexte de WordPress, il y a une difficulté supplémentaire: l’application génère beaucoup de requêtes “légitimes” qui ressemblent à des patterns d’attaque quand on les regarde de loin. Une recherche, un formulaire, un upload, une requête vers l’API REST, un plugin de cache ou un thème qui charge des ressources avec des paramètres, tout cela peut produire des chaînes qui déclenchent des règles trop agressives.
Je vous propose une approche pratique, avec des exemples concrets de configuration et les pièges classiques. L’objectif est simple: renforcer sécurité WordPress avec un WAF réellement utile, sans dégrader l’expérience.
Ce que le WAF doit protéger, et ce qu’il ne fait pas
Un WAF se place entre le client et votre site. Il inspecte les requêtes, repère des comportements suspects et applique des règles, soit en bloquant, soit en “challenging” (par exemple via un mécanisme de vérification). Il est particulièrement efficace contre des attaques automatisées et des tentatives connues: injections SQL, scripts malveillants, traversal de fichiers, patterns de scans, mauvaises requêtes vers des endpoints sensibles.
En revanche, un WAF ne remplace pas:
- la mise à jour des plugins et du noyau WordPress, la configuration correcte des permissions côté serveur, l’hygiène des identifiants (mots de passe forts, limitation des tentatives, 2FA), et une stratégie d’observabilité (logs, métriques, alertes).
Le WAF est une couche, et souvent la couche la plus visible, mais elle fonctionne bien quand elle s’intègre aux autres.
Si vous gérez plusieurs sites WordPress, vous verrez aussi une réalité: chaque architecture produit ses propres “bruits”. Un multisite avec beaucoup d’API REST et un thème dynamique n’a pas les mêmes flux qu’un blog statique, même si WordPress est identique.
Commencer par cartographier vos flux WordPress
Avant de toucher aux règles, j’ai pris l’habitude de faire un inventaire rapide des routes et des comportements attendus. Cela évite une mauvaise surprise au premier blocage.
Le point le plus important: identifier les endroits qui reçoivent de l’entrée utilisateur et ceux qui doivent être exposés au public.
Dans WordPress, les zones typiques impliquent:
- formulaire de connexion et de mot de passe perdu, recherche interne, pages de contenu avec paramètres, endpoints d’administration (souvent derrière une authentification, mais pas toujours), API REST (très utile pour des thèmes modernes, des apps, du headless), gestion des uploads et des fichiers (où les attaques par traversal et scripts trouvent parfois un terrain).
Une fois que vous savez ce qui est “normal” pour votre site, le WAF devient un outil de décision, pas un générateur de blocages aléatoires.
Dans la pratique, je conseille de commencer en mode “surveillance” (ou score plus doux) pendant quelques jours, surtout si votre trafic inclut des usages variés. Vous voulez observer les faux positifs avant de durcir.
La logique de réglage: sévérité, surface, exceptions
La configuration d’un WAF ressemble souvent à un équilibre entre trois axes:
1) La sévérité globale
Beaucoup d’outils proposent un niveau de protection (bas, moyen, élevé). Monter trop vite augmente la probabilité d’empêcher des comportements légitimes. Je préfère avancer par paliers, par exemple “moyen” puis “élevé” après correction des exceptions.
2) La surface à protéger
Un WAF peut inspecter tout le trafic. Dans un monde idéal, vous limitez aussi l’exposition: ne pas exposer des endpoints inutiles, éviter des routes d’administration accessibles publiquement sans contrôle, réduire les plugins qui créent des endpoints additionnels.3) Les exceptions maîtrisées
C’est ici que se joue la stabilité. Une exception bien pensée cible un cas réel, avec une expression précise (par chemin, par méthode HTTP, par paramètre), et idéalement seulement pour une fenêtre de temps si vous êtes en phase de durcissement.Les erreurs fréquentes sont: créer des exceptions trop larges (“autoriser tout ce qui ressemble à X”), ou les oublier après un changement de plugin.
Exemple 1: Cloudflare WAF (règles gérées et durcissement progressif)
Prenons un cas courant: WordPress derrière Cloudflare. L’approche que j’utilise est proche, quelle que soit la plateforme, mais les noms de réglage varient.
Activer une protection de base, puis ajuster
Sur Cloudflare, vous pouvez activer des règles gérées et ajuster le niveau de sécurité. Le piège est de “tout mettre à fond” dès le premier jour. La conséquence, ce sont des blocages sur des requêtes qui ressemblent à de l’injection, par exemple des paramètres envoyés par des plugins de formulaire ou des outils de recherche.
Ma méthode:
- passer d’abord par un niveau intermédiaire, observer les événements “bloqués” ou “challenged”, vérifier si les requêtes bloquées concernent des pages critiques (connexion, recherche, checkout, formulaires), puis ajouter des règles ciblées plutôt que baisser le niveau global.
Je me souviens d’un site WordPress avec un plugin de recherche avancée. Le WAF déclenchait régulièrement sur des paramètres de requête, pas parce que le plugin était “mal”, mais parce qu’il renvoyait des patterns qui ressemblent à certaines chaînes d’attaque. En ajoutant une exception ciblée sur le chemin de recherche et en limitant la condition à des méthodes attendues, on a gardé la protection sans casser l’usage.
Créer des règles personnalisées avec intention
Quand vous devez ajouter une exception, évitez la tolérance totale. Préférez des conditions précises, par exemple:
- autoriser un endpoint REST spécifique seulement si une origine attendue est présente, autoriser un chemin de webhook seulement sur une méthode et une signature attendues, laisser le WAF bloquer le reste.
Si votre site reçoit des webhooks d’un outil externe, l’erreur typique est de remplacer https://gardewp.fr/securite-wordpress/ un secret par “une exception WAF”. Un secret reste un secret, même avec un WAF. L’exception sert à éviter les faux positifs, pas à neutraliser la logique de sécurité.
Exemple 2: AWS WAF (web ACL, règles gérées, priorité)
Sur AWS, on parle de Web ACL, avec des règles, des actions et des priorités. Là encore, les règles gérées peuvent couvrir une grande partie des signatures connues. Le travail consiste à ordonner et à affiner.
Un WAF sur AWS bien géré suit un principe simple: commencer avec des règles gérées raisonnables, puis ajouter des règles spécifiques à votre WordPress si nécessaire.
Priorités et “shadowing” des règles
Un piège très concret dans AWS, c’est l’ordre des règles. Si une règle “autoriser” trop large passe avant une règle “bloquer”, vous neutralisez une partie de la protection sans le vouloir.
Je traite ça comme une cartographie logique:
- d’abord, des règles qui bloquent ou challengent sur des patterns clairement malveillants, ensuite, des règles spécifiques aux endpoints légitimes qui nécessitent une adaptation, enfin, une règle de fallback cohérente.
Quand on ne respecte pas cet ordre, on obtient un WAF qui semble “actif”, mais qui ne protège pas ce qu’on croit.
Exemple d’adaptation: API REST et authentification
Beaucoup de sites WordPress modernes utilisent l’API REST pour des formulaires, des mises à jour de contenu, ou des composants front. Selon votre configuration, certaines routes REST sont publiques (lecture), d’autres exigent une authentification (écriture).
Un bon compromis consiste à:
- autoriser la lecture publique sur des routes prévues, bloquer ou challenger plus fermement les tentatives d’écriture non authentifiées, éviter de “laisser passer” toute l’API REST.
Si vous utilisez un headless ou des apps mobiles, vous pouvez aussi restreindre davantage: provenance réseau, token d’auth, ou un mécanisme de validation applicative. Le WAF aide au triage, votre application valide ce qui doit l’être.
Ce qu’il faut configurer spécifiquement pour WordPress
Les WAF généralistes font du bon travail sur des patterns d’injection et de scanning. Mais WordPress a des caractéristiques qui méritent des réglages plus intentionnels.
Les endpoints d’administration
Même si votre WordPress est “caché” derrière un chemin d’administration spécifique, ce chemin n’est pas une sécurité en soi. Un WAF peut aider à réduire les tentatives automatisées sur:
- la connexion, le mot de passe perdu, les actions AJAX liées au login, les endpoints qui ne devraient pas être accessibles sans session.
Le bon réglage n’est pas forcément “bloquer tout”. C’est souvent “challenger ou limiter” quand la requête ne ressemble pas à un humain attendu, tout en gardant une compatibilité avec vos outils légitimes.
Les uploads et la manipulation de fichiers
Les requêtes liées aux médias sont une zone sensible. Le WAF doit pouvoir repérer des patterns de traversal ou de scripts intégrés dans des chemins ou des paramètres. Le piège, c’est qu’un plugin légitime de génération d’image, un processeur de médias, ou un outil externe de conversion peut ajouter des paramètres ou des headers inhabituels.
La règle pragmatique: d’abord vérifier ce que votre WordPress envoie réellement (via les logs applicatifs et les logs WAF), ensuite seulement adapter les exceptions.
L’API REST (cas à part)
WordPress utilise l’API REST de façon très variable selon les thèmes et plugins. Un WAF peut vous protéger contre des tentatives d’injection via des paramètres REST. Mais si vous bloquez trop, vous cassez:
- affichage dynamique, formulaires qui envoient des requêtes AJAX, actions de plugin (newsletter, réservation, commentaires, etc.).
Je recommande de traiter l’API REST comme un ensemble de routes: certaines peuvent être publiques, d’autres non. Si votre WAF vous permet de cibler par chemin et méthode, c’est exactement là qu’il faut le faire.
Réduire les faux positifs, sans perdre la protection
Les faux positifs sont le nerf de la guerre. Ils sont aussi la raison numéro un pour laquelle des équipes finissent par désactiver un WAF.
Ce qui marche bien dans les retours terrain, c’est une boucle “observer, mesurer, ajuster”:
- observer les événements WAF, associer chaque blocage à une requête réelle (chemin, méthode, paramètre), décider si c’est un vrai positif, un faux positif, ou un “incident à traiter autrement”.
Parfois, la bonne action n’est même pas une exception WAF. C’est une correction applicative. Exemple fréquent: un formulaire qui envoie des champs inattendus, parce que le front n’est pas à jour ou parce que des données proviennent d’un composant cassé. Le WAF bloque le pattern, mais la vraie cause est dans l’application.
Cas pratiques: trois réglages “souvent rentables”
Je regroupe ici des ajustements que j’ai vus revenir plusieurs fois sur des installations WordPress, avec des bénéfices rapides. L’idée n’est pas de copier coller, mais d’adapter.
1) Cibler les méthodes HTTP
Beaucoup d’attaques opportunistes utilisent des requêtes répétitives, parfois avec des méthodes qui ne devraient pas être utilisées sur un chemin donné. Si votre WAF vous permet de restreindre par méthode, vous réduisez fortement le risque sans toucher aux pages normales.
2) Durcir les chemins sensibles, pas tout le site
WordPress ne devrait pas nécessiter autant de tolérance partout. Mettre un WAF très strict sur:
- les endpoints de login, les actions d’auth, certaines routes REST en écriture, Tandis que vous gardez un niveau plus doux ailleurs, améliore la cohérence.
3) Utiliser le challenge au bon endroit
Le challenge (selon l’outil: captcha, vérification, mode JS) a un coût en friction. Si vous le déclenchez sur une page critique pour un robot légitime (monitoring, indexation, preuve de disponibilité), vous vous créez un problème opérationnel. À l’inverse, l’activer sur une zone où les attaques sont fréquentes, comme des tentatives répétées sur l’auth, est souvent un bon compromis.
Mini-checklist de déploiement (pour éviter le “mur de blocages”)
Voici une liste courte que je garde en tête avant de passer un WAF en mode strict:
- Vérifier les endpoints réellement utilisés par vos formulaires, votre login et votre API REST, via logs ou tests navigateur Mettre un mode de surveillance d’abord, puis augmenter la sévérité par paliers Ajouter des exceptions uniquement pour des chemins et méthodes précis, pas pour des familles entières de paramètres Contrôler l’impact sur les bots utiles (monitoring, indexation), et prévoir des exemptions documentées Conserver un historique des changements WAF, pour corriger vite en cas de régression
C’est souvent plus efficace que de chercher “la règle parfaite” dès le départ.
Exemples de règles ciblées (par intention, pas par panique)
Dans une configuration WAF, le style de règle compte autant que la règle elle même. Je pense en termes d’intention: bloquer ce qui est manifestement malveillant, challenger ce qui est suspect mais pas certain, laisser passer ce qui est attendu.
Voici quatre idées de règles ciblées, typiquement utiles avec WordPress, à adapter à votre plateforme:
- Bloquer les tentatives de requêtes vers les routes d’auth avec un pattern d’injection connu, surtout quand elles proviennent de sources non authentifiées Challenger les requêtes vers le login quand elles dépassent un seuil de répétition sur une courte période Autoriser l’API REST en lecture sur des routes publiques, tout en augmentant la sévérité sur les méthodes “écriture” sans session Appliquer une règle plus tolérante sur un endpoint de recherche spécifique, mais uniquement pour les paramètres attendus et avec une validation côté application
L’erreur classique est d’élargir l’exception à “tout ce qui concerne la recherche”. Si vous faites ça, vous ouvrez une porte aux requêtes malformées qui utilisent la même route.
Comment lire les logs WAF sans se noyer
Quand le WAF commence à produire des événements, il y a deux risques: ignorer trop longtemps, ou regarder au hasard.
Un bon travail de tri consiste à:
- filtrer par chemin et méthode, examiner un échantillon de requêtes bloquées ou challengées, recouper avec les logs applicatifs (WordPress, web server, PHP-FPM) pour comprendre si l’événement correspond à une action réelle.
Si vous voyez que 80 pour cent des événements WAF concernent une route non critique, et que le reste correspond à des faux positifs identifiables, vous pouvez ajuster rapidement. Si au contraire vous bloquez beaucoup sur des routes critiques, ralentissez et revenez en arrière: c’est souvent le signe d’une exception trop large ou d’un niveau trop agressif.
Trade-offs concrets: performance, compatibilité, sécurité
Augmenter la sécurité via un WAF a presque toujours un impact indirect sur la performance ou la compatibilité.
- Plus de règles et une inspection plus profonde peuvent augmenter la latence. Sur un site très fréquenté, cela se mesure et se ressent. Un challenge trop fréquent dégrade l’expérience, surtout pour des utilisateurs mobiles ou des réseaux “captifs” qui déclenchent des signaux atypiques. Des règles trop strictes cassent des plugins légitimes. Un plugin de formulaire peut ajouter des paramètres de suivi, un plugin d’export peut appeler une route interne, un thème peut charger des données via AJAX avec des headers spécifiques.
Le bon équilibre vient rarement d’un réglage unique. Il vient d’une série de micro-ajustements et d’une validation fonctionnelle, par exemple tester le login, un formulaire, l’upload d’un média, et les fonctionnalités qui consomment l’API REST.
Déploiement conseillé: rythme et validation
Le rythme de déploiement dépend de votre site. Un blog simple tolère plus facilement des paliers courts, un site e-commerce ou une plateforme de réservation nécessite plus de tests.
En pratique, je procède souvent ainsi:
- démarrer en mode surveillance sur quelques endpoints sensibles, vérifier que les actions clés ne cassent pas, durcir en élargissant progressivement la couverture, puis maintenir un cycle de correction quand un plugin évolue.
Le point que beaucoup ratent: un WAF doit suivre la vie du site. Un changement de plugin ou de thème peut modifier les requêtes. Si vous ne revalidez pas, vous transformez votre WAF en source de pannes.
Renforcer sécurité WordPress sans “se tirer une balle dans le pied”
Un WAF bien configuré ne se contente pas de bloquer. Il vous aide à mieux comprendre ce qui attaque votre site et ce qui, au quotidien, ressemble à une attaque.
La bonne approche pour renforcer sécurité WordPress, c’est:
- protéger les zones sensibles, limiter les faux positifs par ciblage précis, garder une marge de compatibilité, et surtout, corriger la cause quand c’est l’application qui envoie des requêtes surprenantes.
Si vous avez déjà un WAF “en place” mais trop strict, ne cherchez pas à tout désactiver. Commencez par identifier le type de faux positifs. Souvent, il suffit de remplacer une exception trop large par une règle plus fine.
Si vous voulez, décrivez-moi votre contexte (hébergeur ou CDN, type de WAF, endpoints que vous utilisez, si vous avez l’API REST et si vous recevez des webhooks). Je peux vous proposer un jeu de règles cohérent, avec le niveau de sévérité et les emplacements où mettre des exceptions, de manière à renforcer la sécurité sans casser le site.