Pare-feu applicatif web (WAF) : arrêtez les attaques sans casser votre site
Une injection glissée dans un formulaire, une faille publiée dans votre CMS : une seule requête suffit pour atteindre vos données. Klacos lit chaque requête avant votre serveur et arrête celles qui cherchent une faille. Il commence par observer, vous montre ce qu’il aurait bloqué, et une exception se pose en un clic : vos clients ne paient pas le prix d’un réglage trop strict.
Pourquoi tant de sites laissent leur pare-feu éteint
Des refus qui coûtent cher
Un formulaire de commande refusé, un éditeur d’articles qui ne peut plus enregistrer sa page : il suffit qu’un champ ressemble à une attaque. Après un incident de ce genre, le pare-feu reste souvent éteint.
Des failles corrigées trop tard
Entre l’annonce d’une faille dans votre CMS ou une extension et sa mise à jour sur votre site, il s’écoule des jours. Pendant ce temps, la faille est publique.
Des requêtes jugées une à une
Celui qui teste vos formulaires à la recherche d’une injection n’est pas un visiteur ordinaire sur le reste de votre site. Un pare-feu qui juge chaque requête isolément ne le sait pas.
Ces attaques visent l’application elle-même : ses formulaires, ses API, ses extensions. Elles sont automatisées, et une faille publiée est essayée en masse par des scripts bien avant que la plupart des sites aient fait leur mise à jour.
Ce que vous devriez attendre d’un pare-feu applicatif : qu’il vous montre ce qu’il bloquerait avant de bloquer, qu’une exception ne vous oblige pas à tout désactiver, et qu’il sache qui envoie la requête.
Commencez en observation, bloquez quand vous êtes prêt
Chaque site a un seul réglage : désactivé, en observation, puis blocage, à une sensibilité que vous choisissez. En observation, rien n’est refusé. La console liste chaque déclenchement par règle, par chemin et par adresse, et met en avant ceux qui ressemblent à de faux positifs : vous voyez ce que le pare-feu aurait arrêté sur votre propre trafic, et qui.
Depuis un déclenchement, vous créez l’exception qui convient : ce chemin, ce paramètre, cette règle. Le champ de votre éditeur d’articles qui contient du HTML garde son HTML, et le reste du site reste protégé. Quand la liste est propre, vous passez au blocage, puis vous montez la sensibilité si vous le souhaitez.
Une requête bloquée reçoit une page qui donne sa référence, ou une réponse structurée pour une API. Vous la retrouvez dans la console avec la règle qui l’a arrêtée, comme chaque décision expliquée par Klacos.
Un pare-feu que vous réglez au lieu de le subir
Les attaques courantes
Correction virtuelle
Toute la requête
Les attaques déguisées
Observation d’abord
Un seul réglage
Exceptions en un clic
Lié à l’anti-bot
Le pare-feu tourne dans le service géré, opéré dans l’Union européenne, ou sur vos propres serveurs, console comprise.
Une faille publiée, bloquée avant votre mise à jour
Quand une faille est annoncée dans un logiciel que vous utilisez, une règle de correction virtuelle arrête les tentatives qui l’exploitent, devant votre site, dès qu’elle est posée. Vous mettez à jour à votre rythme, sans laisser la porte ouverte en attendant.
Nous tenons les règles à jour : vous n’avez ni liste à télécharger ni abonnement à gérer. La correction virtuelle vous donne du temps ; elle ne remplace pas la mise à jour, qui reste la seule façon de fermer une faille.
Une attaque en dit long sur celui qui l’envoie
Le pare-feu applicatif et la protection anti-bot lisent la même visite. Une règle déclenchée nourrit l’avis sur le visiteur : celui qui cherche une injection dans vos formulaires est surveillé de plus près sur tout votre site, même quand ses requêtes suivantes paraissent anodines.
Pour une requête douteuse, vous pouvez choisir la vérification invisible plutôt que le blocage : le navigateur d’un visiteur la passe sans rien afficher, et un script d’attaque doit la franchir avant d’aller plus loin. Celui qui enchaîne les tentatives se heurte aussi à la limitation de débit, par adresse, par réseau et par route. Le pare-feu fait partie de la protection de votre site dans son ensemble : toutes ses capacités partagent la même lecture de chaque visite.
Questions sur le pare-feu applicatif
Faut-il modifier mon application ?
Non. Le pare-feu fait partie du service placé devant votre site. Votre code et votre serveur ne changent pas.
Remplace-t-il les mises à jour de mon CMS ?
Non. Il arrête les attaques connues et vous laisse le temps de corriger, mais une faille reste ouverte tant que le logiciel n’est pas à jour.
Mes API sont-elles protégées ?
Oui. Le contenu JSON et XML est inspecté comme celui des formulaires, et une requête bloquée reçoit une réponse structurée avec sa référence, pas une page HTML.
Protège-t-il contre les attaques par saturation ?
Les rafales de requêtes et les connexions qui s’éternisent relèvent de la limitation de débit, par adresse, par réseau et par route. Une attaque volumétrique qui sature la liaison réseau avant d’atteindre un service web n’est pas couverte : elle se traite chez votre hébergeur.
Et les en-têtes de sécurité ?
Le jeu courant (HSTS, protection contre la confusion de type de contenu, politique de référent) s’ajoute d’un bouton, site par site. Rien n’est imposé.
Voyez ce que le pare-feu aurait arrêté, avant qu’il bloque quoi que ce soit
Demandez un accès anticipé : le pare-feu commence en observation, sur votre propre trafic. Ou parlons des formulaires et des API que vous voulez protéger.