Scan automatique sur /wp-login.php, tentatives SQLi sur ?id=1' OR '1'='1, robots qui énumèrent /wp-json/. Une partie rebondit sur le WAF du CDN avec un code 403 — le reste atteint PHP parce qu'une route custom du plugin ne matchait aucune règle. L'équipe croyait être « protégée par le WAF » ; en réalité, elle avait réduit le bruit, pas éliminé le risque.
Ce scénario est fréquent dès qu'un pare-feu applicatif est activé sans priorisation. Le WAF filtre des signatures connues — injections SQL, XSS réfléchi, traversées de chemin — mais ne comprend pas votre logique métier. Un utilisateur autorisé peut abuser d'une fonction légitime ; une faille zero-day non signée passe tant qu'aucune règle ne la reconnaît.
Un WAF (Web Application Firewall) inspecte HTTP et applique des règles avant votre application. Il complète le code — il ne remplace ni requêtes préparées, ni contrôle d'accès métier, ni mises à jour de sécurité.
Pour un site WordPress, combinez mises à jour régulières, moindre privilège sur les comptes admin, et WAF en filet — dans cet ordre, sans exception. Voir malware en mutualisé pour les risques spécifiques à l'hébergement partagé.
Ce qu'un WAF attrape bien
Les signatures SQLi, XSS et traversées de chemin connues. Les scans massifs — volume, agents utilisateur suspects, géolocalisation douteuse. Les robots — challenge JavaScript, captcha, limitation de débit couplée — voir DDoS sur petit site. Le correctif virtuel temporaire — règle de blocage sur CVE plugin en attendant la mise à jour.
| Couche | WAF | Code sécurisé |
|---|---|---|
| Injection SQL | Signatures + anomalies | Requêtes préparées |
| XSS réfléchi | Filtrage patterns | Échappement sortie |
| IDOR métier | Non | Autorisation applicative |
| Upload malveillant | Heuristique extension/MIME | Validation serveur stricte |
Le WAF filtre le bruit connu. Votre logique métier reste votre responsabilité.
Où placer le WAF
Edge CDN (Cloudflare, etc.) — filtre avant l'origine, absorbe le volume ; moins de visibilité sur le corps chiffré de bout en bout si TLS se termine au edge.
Reverse proxy origine (ModSecurity + nginx) — contrôle fin, journaux locaux ; vous opérez règles et mises à jour.
Hébergeur mutualisé — WAF managé limité ; peu de règles personnalisées.
Choix souvent hybride : CDN pour le volumétrique plus ModSecurity sur routes admin sensibles. Voir aussi WAF ou correction code pour la priorisation.
Le WAF edge ne voit pas toujours le corps des requêtes chiffrées de bout en bout. Si votre menace principale est une faille plugin WordPress non patchée, le correctif reste la mise à jour — le WAF ne fait que retarder l'exploitation des signatures connues.
Faux positifs : discipline
Panier e-commerce, API mobile, éditeur riche en POST — déclencheurs fréquents. Whitelist règle précise (URI + paramètre), pas « désactiver la sécurité ». Retestez après chaque déploiement majeur. Corrélez journaux application — 403 WAF vs 500 PHP.
Limites honnêtes
Faille zero-day non signée. HTTPS de bout en bout sans déchiffrement au edge = inspection limitée. Faux sentiment de sécurité qui retarde le patch plugin. Coût latence — règles lourdes sur chaque requête.
Avant d'activer le blocage en production, mesurez aussi l'impact sur les parcours légitimes : un panier e-commerce ou une API mobile peut envoyer des payloads qui ressemblent à des attaques sans en être. C'est là que le mode journalisation devient indispensable pour distinguer bruit et vrai positif.
Le sommet : le WAF masque la dette — jusqu'à la règle qui manque
Positionnez-le comme couche 2 après hygiène code et durcissement — SSH sécurisé, pare-feu VPS.
Décider et avancer sans angle mort
Corrigez d'abord CMS et plugins prioritaires, activez ensuite un WAF CDN ou ModSecurity en mode journalisation, puis ajustez les faux positifs documentés un par un. Couplez limitation de débit et surveillance des pics de 403, et comparez les offres WAF via notre annuaire en vérifiant qui opère les règles et qui répond en cas de blocage légitime.
Questions fréquentes
WAF ou correction du code en priorité ?
Corrigez les vulnérabilités connues, puis configurez le WAF en filet. Un WAF seul laisse passer les abus de logique métier et les failles zero-day non signées.
WAF mutualisé vs Cloudflare ?
Mutualisé : souvent ModSecurity basique. CDN : règles OWASP managées, mais trafic proxyé — vérifiez l'impact RGPD.
Comment gérer les faux positifs ?
Mode journalisation d'abord, liste blanche ciblée, ne désactivez pas tout OWASP en production.
Un WAF protège-t-il des failles plugins WordPress ?
Parfois sur patterns connus — pas garanti. Mises à jour et moindre privilège restent essentiels.
Un WAF complète le code comme un airbag complète la ceinture — ne remplace pas le fait de freiner avant le mur.