Un pare-feu réseau classique contrôle les ports et les adresses IP, mais laisse passer sans distinction tout le trafic web sur le port 443 ; un pare-feu applicatif va plus loin en examinant le contenu même de chaque requête HTTP, un peu comme un vigile qui inspecterait le contenu des sacs plutôt que de simplement vérifier un badge d’entrée.
Déploiement autour de WordPress
Il existe deux grandes familles : un service en amont du serveur, comme un CDN qui filtre le trafic avant qu’il n’atteigne l’hébergement, ou une extension WordPress qui intercepte les requêtes une fois arrivées sur le serveur, via des hooks très tôt dans le cycle de chargement. La première approche bloque le trafic malveillant avant même qu’il ne consomme des ressources serveur, ce que la seconde ne peut pas faire.
Ce qu’il détecte typiquement
- Motifs d’injection SQL dans les paramètres d’URL.
- Tentatives de connexion répétées (force brute).
- Signatures connues de vulnérabilités d’extensions populaires.
- Requêtes vers des chemins sensibles habituellement ciblés par des robots.
Bon à savoir
Un pare-feu applicatif complète les bonnes pratiques de code mais ne les remplace jamais : il peut bloquer l’exploitation connue d’une faille, mais une extension mal codée reste vulnérable de fond, et une règle mal réglée peut aussi bloquer par erreur du trafic légitime, par exemple des appels API venant d’une application mobile officielle. Un site correctement protégé combine généralement plusieurs couches : un pare-feu en amont, des mises à jour régulières, et un code applicatif qui applique lui-même échappement et validation, sans jamais reporter toute la responsabilité sur le seul filtrage réseau.