Le filtre devant le site : utile, inclus, ou superflu
Ou : un videur à l’entrée ne répare pas l’escalier de secours.
La réponse courte : un pare-feu applicatif (WAF, pour Web Application Firewall) examine chaque requête envoyée au site et bloque celles qui ressemblent à une attaque connue, comme une injection SQL ou l’insertion d’un script. Sur un mutualisé, il est souvent déjà inclus : Infomaniak active ModSecurity par défaut sur ses serveurs, sans possibilité de le désactiver, OVHcloud le propose à activer dans son panneau, o2switch fournit TigerProtect et PlanetHoster un « WAF Pro ». Utile, donc, et rarement à acheter en plus pour un petit site ; mais insuffisant seul, parce qu’il ne corrige pas l’extension vulnérable qu’il protège. C’est une brique de la sécurité côté hébergeur, pas un substitut aux mises à jour.
Un WAF fonctionne avec des règles, par exemple l’OWASP Core Rule Set, un jeu de règles libre largement utilisé avec ModSecurity. Il arrête bien les attaques qui suivent un schéma connu, et beaucoup moins celles qui exploitent une faille avec des requêtes d’apparence normale : un formulaire qui oublie de vérifier les droits de l’utilisateur ne déclenche aucune signature.
Pour qui : un indépendant ou une petite entreprise qui veut un site sur un mutualisé avec un pare-feu applicatif actif d’office, sans réglage à faire.
À partir de : 5,75 € HT par mois pour l’hébergement web Infomaniak, facturé à l’année par défaut, sans prix promotionnel affiché (relevé du 12 novembre 2026), ModSecurity et antivirus inclus.
Pour démarrer : commander l’hébergement web Infomaniak, installer le CMS, puis activer ses mises à jour automatiques, que le filtre ne remplace pas.
Pare-feu applicatif web (WAF) : les filtres inclus et les services externes
| Filtre | Fourni par | Réglage par le client | Coût relevé |
|---|---|---|---|
| ModSecurity | Infomaniak | actif par défaut, impossible à désactiver, règles communes à tout le serveur | inclus dans l’hébergement |
| ModSecurity, « pare-feu applicatif » | OVHcloud | à activer pour tout l’hébergement ou par domaine ; configuration non modifiable | inclus dans l’hébergement |
| TigerProtect, « Firewall Web IA », et l’antivirus ImunifyAV+ | o2switch | non détaillé sur la page de l’offre | inclus dans l’offre |
| « WAF Pro » : ModSecurity et plus de 200 règles OWASP | PlanetHoster | non détaillé sur la page de l’offre | inclus dans les offres The World |
| Free Managed Ruleset | Cloudflare, offre gratuite | règles gérées par Cloudflare | gratuit |
| Cloudflare Managed Ruleset et OWASP Core Ruleset | Cloudflare, offres Pro et supérieures | règles réglables | offre payante |
Relevé le 12 novembre 2026 dans la documentation d’Infomaniak, d’OVHcloud et de Cloudflare, et sur les pages d’offres d’o2switch et de PlanetHoster.
La différence entre les deux familles tient à la position. Le filtre de l’hébergeur tourne sur le serveur, devant chaque site : il ne coûte rien de plus et ne demande rien, mais il applique les mêmes règles à tout le monde. Chez Infomaniak, la FAQ précise que le réglage est « global au serveur » ; chez OVHcloud, le guide d’activation du pare-feu applicatif indique qu’on ne peut pas modifier sa configuration, infrastructure partagée oblige. Le service externe, lui, se place devant l’hébergement, en général en reprenant la gestion du DNS : il filtre avant que la requête n’atteigne le serveur, et ses règles se règlent site par site.
Sur un CMS pas à jour, le résultat dépend de la faille. Si elle est connue et exploitée par un script public qui envoie une injection reconnaissable, une règle générique a de bonnes chances de l’arrêter. Si l’exploitation passe par une requête banale, par exemple l’appel à une fonction d’extension accessible sans contrôle d’accès, le filtre la laisse passer, parce qu’elle ne ressemble à rien de suspect. Le WAF achète du temps entre la publication d’une faille et votre mise à jour ; il ne remplace pas la mise à jour.
Reste le revers : les faux positifs. Un filtre qui bloque une requête légitime renvoie une erreur 403 à votre visiteur, ou à vous dans l’espace d’administration. Infomaniak documente un cas où un réglage de langue absent dans le navigateur déclenche une règle ; comme on ne peut pas désactiver ModSecurity sur ses serveurs, la solution passe par le support. C’est le prix d’un filtre que personne n’a à configurer.
Faut-il donc un service externe ? Pour un site vitrine ou un blog à jour, le filtre inclus suffit. Les règles gratuites de Cloudflare ajoutent une couche sans frais, et ses offres payantes donnent accès à l’OWASP Core Ruleset et aux règles gérées complètes. Un service externe se justifie pour une boutique visée par des robots, un site qu’on ne peut pas mettre à jour vite, ou un besoin de limiter le nombre de requêtes par visiteur.
Quand le filtre n’a pas suffi
Un site piraté malgré le pare-feu applicatif n’a rien d’exceptionnel : la requête qui a servi ressemblait peut-être à une visite ordinaire. Les journaux du filtre aident alors à dater l’intrusion, première étape avant de restaurer et de corriger, dans l’ordre décrit par les premières mesures après un piratage.
Les requêtes par milliers
Un pare-feu applicatif peut écarter une partie d’une attaque applicative par saturation, mais il ne protège pas l’adresse IP d’un mutualisé contre une attaque volumétrique. Le partage des rôles entre filtre, hébergeur et CDN est expliqué dans la page sur les attaques DDoS contre un site hébergé.