Mon hébergeur dit que son pare-feu suffit : est-ce vrai

Ce qu’un pare-feu applicatif fait réellement

Un pare-feu applicatif s’intercale entre le visiteur et votre boutique : il lit les requêtes avant qu’elles n’atteignent votre code. Il travaille sur trois registres. Il reconnaît des schémas d’attaque déjà connus et catalogués, et refuse les requêtes qui leur ressemblent. Il limite le débit, c’est-à-dire le nombre de requêtes qu’une même source peut envoyer dans un intervalle donné. Il bloque des sources entières, par adresse ou par réputation, quand elles se comportent comme des outils automatisés plutôt que comme des clients.

Ce n’est pas rien, et les volumes le montrent. Sur une faille critique d’une extension de formulaires WordPress corrigée en mars 2026, Wordfence a bloqué plus de 29 300 tentatives d’exploitation. Sur une faille d’un connecteur d’e-mail installé sur environ 100 000 sites, le total dépasse 17 millions de tentatives, avec un pic de plus de 4 millions de requêtes bloquées en une seule journée les 6 et 7 juin 2026. Sur un contournement d’authentification touchant une extension de statistiques, plus de 7 400 attaques ont été bloquées en 24 heures. Quand ce filtrage fonctionne, il absorbe un bruit considérable et, parfois, une compromission.

Ce n’est pas non plus une position marginale. Après la vague d’attaques par injection SQL visant des modules tiers PrestaShop, les recommandations publiées par le projet citent explicitement le déploiement d’un pare-feu applicatif — aux côtés de la mise à jour de tous les modules natifs et tiers, de l’usage d’un préfixe de base de données personnalisé et de sauvegardes régulières. Le pare-feu y figure comme un élément d’une liste, pas comme la liste.

Ce qu’il ne peut pas faire

Un pare-feu reconnaît des formes. Quand l’exploitation d’une faille prend la forme d’un usage normal du site, il n’a plus rien à reconnaître. C’est le point le plus important de cette page, et il est documenté : sur un module de fenêtres surgissantes pour PrestaShop, l’avis de sécurité note que les tentatives apparaissent dans les journaux du site comme de simples requêtes POST /, donc très difficiles à distinguer sans outil dédié. Le même avis recommande des règles de pare-feu, mais en complément de la mise à jour du module — jamais à sa place.

Trois autres situations lui échappent par construction :

• Une extension déjà piégée. Quand du code malveillant arrive par le canal de distribution de l’éditeur et s’exécute côté serveur, il n’y a aucune requête entrante suspecte à filtrer. Le mal est déjà à l’intérieur.
• Une fuite par un point d’accès légitime mal protégé. Un dossier de journaux laissé lisible publiquement, ou un point d’accès d’API qui répond sans vérifier les droits, répond à une requête parfaitement bien formée. Rien à bloquer, du point de vue du filtre.
• Un accès obtenu avec des identifiants valides. Un pare-feu ne distingue pas un administrateur légitime d’un attaquant qui utilise le mot de passe de cet administrateur.

À l’échelle de l’écosystème, cela se chiffre. Le rapport Patchstack sur l’année 2025 indique que moins de 26 % des attaques sont bloquées par les protections des hébergeurs. C’est une part réelle, ce n’est pas une couverture.

Le cas où il est vraiment décisif : la fenêtre avant correctif

Il existe une situation où le filtrage change réellement l’issue : entre le moment où une faille est publiée et le moment où vous pouvez appliquer le correctif. Cette fenêtre n’est pas théorique. D’après le même rapport, le délai médian jusqu’à l’exploitation de masse est de 5 heures, et environ la moitié des vulnérabilités à fort impact sont exploitées dans les 24 heures qui suivent la divulgation. Une boutique ne se met pas à jour en cinq heures : il faut sauvegarder, appliquer, tester, et vérifier que le tunnel de commande survit à l’opération.

C’est là qu’une mesure d’attente a du sens. Lors de la mise à jour d’urgence de WordPress publiée le 17 juillet 2026, Tenable a cité, parmi les mesures provisoires, le blocage au niveau du pare-feu applicatif du point d’accès concerné de l’API REST par lots, ainsi que la surveillance des tentatives qui le visent. Le mot important est « provisoire » : on bloque une porte le temps de poser la serrure, on ne considère pas que la porte est réparée. WordPress.org a d’ailleurs activé des mises à jour automatiques forcées sur les versions concernées, ce qui dit assez clairement ce qui règle vraiment le problème.

Un pare-feu vous achète donc du temps, et ce temps a de la valeur quand vous ne pouvez pas mettre à jour immédiatement — parce que le correctif casse un module, parce que la maintenance est planifiée, ou parce qu’aucun correctif n’existe encore. Il ne vous achète rien du tout si vous ne comptez pas mettre à jour ensuite.