Un pare-feu applicatif web, ou WAF (Web Application Firewall), analyse chaque requête HTTP adressée à votre site avant qu’elle n’atteigne WordPress. Il bloque les schémas connus d’attaque – tentatives d’injection SQL, de XSS, d’exploitation de faille – sans que le code du site ait besoin d’être modifié.
Où se place un WAF techniquement
Un WAF peut s’installer à trois niveaux différents, avec des implications différentes :
- Au niveau du serveur ou de l’hébergeur : filtrage avant même que la requête n’atteigne PHP, le plus efficace en termes de performance et de protection
- Via un service tiers en amont (reverse proxy / CDN) : le trafic transite par un réseau externe qui filtre puis relaie vers le serveur d’origine
- Sous forme de plugin WordPress : filtrage au niveau applicatif, dans WordPress lui-même – plus simple à mettre en place mais qui consomme des ressources PHP puisque WordPress a déjà démarré au moment du filtrage
Quelles solutions existent
Le choix dépend surtout du niveau d’hébergement. Un hébergement infogéré WordPress inclut souvent un WAF réseau en amont, invisible pour l’utilisateur mais actif en continu. À défaut, un plugin de sécurité avec module WAF (souvent couplé à un scanner de vulnérabilités) reste une option pertinente sur un hébergement mutualisé classique. Dans tous les cas, un WAF filtre des schémas connus : il ne remplace pas la correction d’une faille, seulement il réduit la fenêtre de risque avant qu’un correctif ne soit appliqué.
Ce qu’un WAF ne fait pas
Un WAF n’empêche pas une faille d’exister : il en limite l’exploitation par des schémas de trafic déjà identifiés comme malveillants. Un correctif de plugin reste indispensable, un WAF n’est qu’une couche de protection complémentaire, pas un substitut à la mise à jour.
