Azure WAF : ajouter une exclusion OWASP/CRS sans affaiblir toute la protection

Une exclusion WAF doit être une correction précise, pas un moyen rapide de faire disparaître un blocage. Quand une règle OWASP/CRS bloque un flux légitime, la tentation est forte de désactiver la règle entière. C’est rarement le bon premier choix. Une exclusion trop large peut retirer une protection utile à toute l’application pour résoudre un seul paramètre gênant.

Le scénario traité ici part d’un faux positif déjà qualifié : une règle WAF bloque un champ connu sur un endpoint précis, l’équipe applicative confirme que le contenu est attendu, et l’équipe sécurité accepte une exception limitée. L’objectif est de traduire cette décision en configuration Azure WAF sans affaiblir inutilement la policy.

Cas fil rouge : autoriser comment sans ouvrir tout le formulaire

Dans le portail partenaire partner.example.com, l’analyse KQL a isolé la règle 942100 sur /partner/comment. Le champ comment est un texte libre, borné côté application et stocké comme chaîne. Les autres champs du formulaire, comme partnerId, caseId ou priority, ne doivent pas être exclus de l’inspection WAF.

La décision de changement est donc volontairement étroite : ne pas désactiver la règle SQLi, ne pas exclure tout le corps de requête, ne pas baisser le niveau de protection du site. L’exception doit porter uniquement sur le nom d’argument comment, pour la règle concernée, dans la policy du portail partenaire.

Définir exactement ce qui doit être exclu

Avant d’ouvrir le portail ou la CLI, il faut écrire la cible. Une exclusion se pense avec plusieurs dimensions : policy concernée, listener ou application, règle, groupe de règles, variable de requête, opérateur de correspondance et justification.

Décision d'exclusion
Policy : wafpol-app-prod
Application : portail partenaire
Règle : 942100
Groupe : REQUEST-942-APPLICATION-ATTACK-SQLI
Variable : RequestArgNames
Sélecteur : comment
Justification : champ texte libre contenant parfois des mots clés SQL légitimes
Durée : à revoir après correction applicative ou revue trimestrielle

Si cette fiche ne peut pas être remplie, l’exclusion est probablement prématurée. Il manque soit l’identification du champ, soit la compréhension de la règle, soit l’accord sur le risque.

Préférer une exclusion par règle

Quand le ruleset le permet, l’exclusion par règle est plus sûre qu’une exclusion globale. Elle dit que tel champ ne doit pas être évalué par telle règle ou tel groupe, au lieu de retirer ce champ de toute inspection WAF. C’est une différence importante.

Exclusion globale
Le champ est ignoré par toutes les règles concernées par le scope global
Risque plus large

Exclusion par groupe
Le champ est ignoré par un groupe de règles
Risque intermédiaire

Exclusion par règle
Le champ est ignoré seulement pour la règle ciblée
Risque plus limité et plus facile à justifier

L’objectif est de garder le maximum de protection autour du payload. Un champ texte peut déclencher une règle SQLi précise sans devoir être ignoré par les protections XSS, protocol enforcement ou autres contrôles.

Exemple avec Azure CLI

La syntaxe exacte dépend de la version du ruleset et du type de policy, mais l’intention reste la même : ajouter une exclusion sur une variable et la rattacher à un ruleset, un groupe et éventuellement une règle précise.

RG=rg-network-prod
POLICY=wafpol-app-prod

az network application-gateway waf-policy managed-rule exclusion rule-set add --resource-group $RG --policy-name $POLICY --match-variable RequestArgNames --selector-match-operator Equals --selector comment --rule-set-type OWASP --rule-set-version 3.2 --rule-group-name REQUEST-942-APPLICATION-ATTACK-SQLI --rules 942100

Cette commande est un exemple de forme. Avant de l’appliquer, il faut vérifier le ruleset réellement utilisé par la policy et la disponibilité des exclusions par règle dans ce contexte. La configuration doit suivre le standard du dépôt d’infrastructure si la plateforme est gérée par IaC.

Valider après changement

Une exclusion ne se valide pas seulement en demandant à l’utilisateur de réessayer. Il faut vérifier que le parcours légitime passe, que la règle ne bloque plus ce cas précis, et que d’autres protections restent actives. Le test doit inclure une fenêtre temporelle claire dans Log Analytics.

let startTime = datetime(2026-05-27 15:00:00);
AzureDiagnostics
| where TimeGenerated > startTime
| where Category == "ApplicationGatewayFirewallLog"
| where requestUri_s has "/partner/comment"
| summarize events=count() by action_s, ruleId_s, message_s
| order by events desc

Si les événements disparaissent complètement, ce n’est pas forcément bon signe. Cela peut signifier que l’exclusion est trop large. Le but est de ne plus bloquer le faux positif, pas de rendre invisible toute activité WAF sur cette route.

Pour le portail partenaire, la validation attendue est plus précise : le partenaire peut soumettre un commentaire contenant un extrait SQL, la règle 942100 ne bloque plus le champ comment, mais une tentative évidente d’injection dans partnerId ou caseId reste détectée. C’est ce test négatif qui prouve que l’exclusion n’a pas affaibli tout le formulaire.

Validation fonctionnelle
Soumettre un commentaire légitime contenant SELECT ou WHERE
Résultat attendu : formulaire accepté

Validation sécurité
Injecter une valeur suspecte dans partnerId ou caseId sur environnement de test
Résultat attendu : WAF détecte ou bloque toujours selon la policy

Validation logs
Vérifier /partner/comment après changement
Résultat attendu : plus de blocage 942100 sur RequestArgNames=comment, autres règles visibles

Prévoir un retour arrière

Une exclusion doit pouvoir être retirée. Le changement doit donc être documenté avec sa commande inverse ou son équivalent IaC. Il faut aussi préciser les conditions de retrait : correction applicative, changement de payload, montée de version du ruleset, nouvelle analyse sécurité.

Retour arrière
Supprimer l'exclusion sur RequestArgNames Equals comment pour la règle 942100
Vérifier pendant 30 minutes les blocages sur /partner/comment
Prévenir l'équipe applicative si le faux positif réapparaît

Conditions de revue
Evolution du formulaire
Changement de version OWASP/CRS ou DRS
Incident sécurité sur le même endpoint
Revue périodique des exclusions WAF

Sans retour arrière, l’exclusion devient permanente par défaut. C’est rarement souhaitable.

Conclusion

Ajouter une exclusion OWASP/CRS dans Azure WAF doit être l’aboutissement d’une analyse, pas son point de départ. La bonne exclusion est spécifique : une policy, une règle, un groupe, une variable, un sélecteur et une justification.

Le principe de sécurité est simple : retirer le moins possible, pendant le moins longtemps possible, avec une preuve avant et après. C’est ce qui permet de corriger un faux positif sans transformer la policy WAF en collection d’exceptions globales impossibles à défendre.