Dompter les faux positifs d'un WAF sans casser votre application

Le vrai coût d’un WAF mal réglé

Un pare-feu applicatif qui bloque trop est parfois plus dangereux qu’un pare-feu qui bloque trop peu. Un faux positif, c’est un vrai client — un acheteur, un partenaire, un formulaire de contact légitime — arrêté par une règle qui a pris son comportement pour une attaque. Il ne voit pas une alerte de sécurité : il voit un site cassé. Et souvent, il ne revient pas.

C’est pour cette raison que beaucoup d’équipes finissent par désactiver leur WAF « parce qu’il gênait la prod ». Le problème n’est presque jamais le jeu de règles lui-même — la base OWASP est solide et maintenue par une large communauté. Le problème est qu’on l’a activé en mode blocage total, sans mesurer ce qu’il ferait sur votre trafic réel. Régler un WAF, c’est apprendre à connaître votre application avant de laisser les règles décider à sa place.

Pourquoi les faux positifs arrivent

Les règles génériques doivent couvrir des millions de sites différents. Elles se déclenchent donc sur des formes qui ressemblent à une attaque mais sont parfaitement normales dans votre contexte :

• Un champ de texte libre où un utilisateur colle légitimement du code, du SQL ou des balises — une documentation technique, un support développeur, un CMS.
• Une API interne qui envoie des charges JSON denses qu’une règle anti-injection interprète mal.
• Un paramètre métier dont le format inhabituel croise, par malchance, une signature d’attaque.

Aucun de ces cas n’est un défaut du jeu de règles. Ce sont des collisions entre une règle générique et une spécificité de votre application — et elles se résolvent par le réglage, pas par la désactivation.

Régler sans voler à l’aveugle : commencer en observation

La pire façon de déployer un WAF est de l’activer en blocage direct sur la production et d’attendre les plaintes. La bonne façon est de commencer en mode observation : les règles évaluent chaque requête et consignent ce qu’elles auraient bloqué, sans rien bloquer réellement. Vous obtenez, sur votre vrai trafic, la liste exacte des règles qui se déclenchent et sur quoi.

À partir de là, le réglage devient méthodique :

• Identifier les règles bruyantes. Une poignée de règles génère souvent l’essentiel des faux positifs. Le journal les fait remonter immédiatement.
• Cibler l’exception, pas la règle entière. Plutôt que de désactiver une protection large, on neutralise son déclenchement sur le seul point de terminaison ou le seul paramètre concerné. La protection reste active partout ailleurs.
• Basculer en blocage progressivement. Une fois le bruit tombé, on active le blocage règle par règle, en surveillant. Le journal d’audit immuable, en ajout seul, garde la trace de chaque changement et de son effet.

Le scoring plutôt que le tout-ou-rien

Une décision binaire — bloqué ou passé — est fragile : une seule règle qui se déclenche par erreur casse une requête entière. Une approche par score d’anomalie est plus tolérante : chaque règle contribue à un total, et seul un franchissement de seuil déclenche une action. Une correspondance isolée et bénigne ne suffit plus à bloquer un client légitime. Combiné au scoring d’entité par apprentissage, qui juge le comportement dans le temps plutôt que la requête isolée, cela réduit nettement le taux de faux positifs sans baisser la garde face aux vraies attaques.

Ce réglage se combine avec le patch virtuel : une règle d’urgence, posée vite, doit justement être surveillée en observation avant blocage, pour ne pas casser du trafic légitime dans la panique.

Souveraineté et visibilité

Tout ce travail de réglage repose sur une donnée : le journal de ce que les règles font sur votre trafic. Cette donnée est sensible et reste sur des nœuds européens (Hetzner, OVH, Scaleway) ; la piste d’audit est immuable et vérifiable, comme l’exige le RGPD. Voyez comment ça fonctionne et l’ensemble des fonctionnalités.

Ce que nous ne prétendons pas

Aucun réglage n’atteint zéro faux positif ET zéro faux négatif à la fois — c’est un compromis, pas un problème à « résoudre » définitivement. Un seuil plus strict attrape plus d’attaques et gêne plus de clients ; un seuil plus souple fait l’inverse. Notre rôle est de vous donner la visibilité et les outils pour placer ce curseur en connaissance de cause, sur votre trafic réel — pas de prétendre à une perfection qui n’existe pas. Côté performance, l’évaluation des règles tient dans un budget de conception de ≤5 ms, mesuré en staging, jamais présenté comme un benchmark de production.

Vous voulez voir ce que les règles déclencheraient sur votre trafic, sans rien bloquer d’abord ? Donnez-nous votre domaine.