Un site équipé d’un pare-feu applicatif actif, avec ses journaux qui affichent des dizaines de tentatives bloquées chaque semaine, donne une impression de protection tangible et mesurable. Cette impression pousse parfois à repousser une mise à jour d’extension jugée risquée pour la compatibilité, en misant sur le pare-feu pour couvrir l’intervalle. Un audit de sécurité, mené sur ce type de configuration, révèle presque systématiquement le même écart entre cette impression et la réalité technique.
Ce qu’un pare-feu applicatif fait réellement
Un pare-feu applicatif, qu’il s’agisse d’une extension WordPress dédiée ou d’une couche placée devant le serveur, filtre le trafic HTTP entrant selon des motifs connus : une tentative d’injection SQL reconnaissable par sa syntaxe, une requête vers un chemin de fichier historiquement associé à une faille publiée, un volume de requêtes anormal depuis une même adresse. Ce filtrage agit en amont du code de l’application, sans jamais le modifier ni corriger la faille qu’il tente de bloquer.
Ce qu’un audit trouve, presque à chaque fois
L’observation qui revient le plus souvent dans ce type d’audit : une extension dont la version installée correspond exactement à celle visée par un correctif de sécurité publié plusieurs mois auparavant, alors que le pare-feu applicatif du site est configuré et actif depuis la même période. La faille corrigée par l’éditeur de l’extension reste pleinement exploitable dans le code lui-même ; seule une partie des tentatives d’exploitation les plus connues et signaturées est interceptée en amont par le pare-feu.
Pourquoi cette confusion s’installe
Le tableau de bord d’un pare-feu applicatif affiche un nombre de menaces bloquées, une donnée concrète et rassurante. La mise à jour d’une extension, à l’inverse, ne produit aucune donnée équivalente : elle disparaît de la liste des actions en attente, sans indicateur visible de ce qu’elle a réellement corrigé. Cette asymétrie de visibilité favorise une priorisation du pare-feu sur les mises à jour, alors que les deux répondent à des besoins différents et non substituables.
Ce que chaque mesure couvre, et ce qu’elle ne couvre pas
- Un pare-feu applicatif filtre des motifs connus au moment de sa mise à jour de signatures ; une technique d’exploitation nouvelle ou peu répandue, non encore signalée, peut passer sans être détectée.
- Une mise à jour d’extension corrige la faille à sa source, mais ne protège en rien contre une faille non encore découverte ou non encore corrigée par l’éditeur.
- Une faille de logique métier, propre au fonctionnement interne d’une extension, échappe généralement à la détection par motif d’un pare-feu applicatif, qui ne connaît pas la logique métier de l’application qu’il protège.
Un pare-feu applicatif réduit la fenêtre de risque entre la publication d’une faille et l’application de son correctif ; il ne referme jamais cette fenêtre à lui seul.
Quoi faire à la place d’un choix exclusif
Les deux mesures se complètent dans un ordre précis : la mise à jour corrige la faille à sa source dès qu’un correctif existe, et le pare-feu applicatif réduit l’exposition pendant l’intervalle qui précède cette correction, ou face à des tentatives génériques qui ne visent aucune faille spécifique. Présenter le pare-feu comme une alternative à la maintenance régulière, plutôt que comme son complément, inverse la priorité que devrait avoir chacune de ces deux mesures dans un plan de sécurité.
Comment reformuler cette priorité auprès d’un client
Présenter la mise à jour comme la mesure première, et le pare-feu applicatif comme une protection additionnelle pendant l’intervalle de mise à jour, aide à justifier un budget de maintenance régulière distinct de l’abonnement au pare-feu. Cette distinction évite qu’un client, en voyant les deux lignes sur une même facture, en déduise à tort qu’elles couvrent un risque identique et qu’une seule des deux suffirait à réduire le coût global.
Notre verdict
Un audit qui trouve un pare-feu applicatif actif et des extensions vulnérables non mises à jour ne constate pas un échec du pare-feu, mais un mauvais arbitrage dans l’ordre des priorités. La maintenance régulière du code reste la mesure qui referme réellement une faille ; le pare-feu applicatif reste une protection en profondeur, jamais un substitut à cette maintenance.
