Règles gérées et règles personnalisées dans WAF : quand rédiger les vôtres

Il existe une croyance répandue selon laquelle il suffit d'activer l'ensemble de règles géré par Cloudflare et l'ensemble de règles de base OWASP pour disposer d'une application protégée. Le principe ignore ce pour quoi ces ensembles de règles ont été conçus – et ce qu’ils ne font délibérément pas.

Les ensembles de règles gérés offrent une protection à large spectre. Ils ont été conçus pour fonctionner sur n’importe quelle application Web, d’un blog WordPress à une API de paiement, sans aucune connaissance de ce qui différencie leur application des autres. C'est précisément ce qui les limite.

Ce que couvrent les ensembles de règles gérés et où ils génèrent des frictions

L'ensemble de règles gérées par Cloudflare est automatiquement mis à jour lorsque Cloudflare détecte de nouveaux kits d'exploitation, des signatures d'attaque à grande échelle et une exploitation active des CVE dans des logiciels populaires. Pour une équipe sans équipe de sécurité dédiée, cela a une réelle valeur ajoutée : une couverture continue sans maintenance manuelle.

L'ensemble de règles de base OWASP fonctionne avec des classes d'attaque cataloguées : injection SQL, XSS, inclusion de fichiers, désérialisation non sécurisée. Le modèle de notation accumule des points lorsque les règles se déclenchent sur la même requête, et une action se produit lorsque le total dépasse un seuil configurable. Cette conception réduit les faux positifs provenant de règles isolées très sensibles, mais ne les élimine pas.

Les faux positifs apparaissent de manière prévisible dans trois contextes. Les points de terminaison d'API qui acceptent JSON avec des guillemets, des apostrophes ou des parenthèses entrent en conflit avec les règles SQLi : le moteur voit le formulaire, pas le contexte. Les panneaux d'administration dotés d'éditeurs de texte enrichi déclenchent des règles XSS lorsque l'utilisateur enregistre du HTML légitime dans un POST. Les points de terminaison de téléchargement binaire activent des règles d'inspection de corps étalonnées par texte. Aucune de ces attaques n’est une attaque ; tous sont des comportements d’application légitimes.

Quelles règles personnalisées vous permettent de faire

Les règles personnalisées fonctionnent avec des connaissances que les ensembles de règles gérés n'auront jamais : le comportement spécifique de votre application, le profil du trafic légitime, les menaces pertinentes pour votre cas d'utilisation.

Le langage d'expression de Cloudflare prend en charge les conditions composées avec and, or et not. Un blocage par pays d'origine ip.geoip.country eq "RU" combiné à http.request.uri.path eq "/api/register" restreint uniquement le point final d'enregistrement, sans toucher au reste. Le champ cf.threat_score gt 10 bloque les adresses IP ayant une mauvaise réputation sans nécessiter de listes noires manuelles.

Les listes d'autorisation pour les sources fiables sont aussi importantes que les règles de blocage. Les IP de surveillance, les CI/CD et les opérateurs internes doivent être exclus de toute inspection avec une règle Autoriser appliquée avant les autres. Sans cela, un bilan de santé renvoie 403 et un déploiement intermédiaire reste bloqué dans une limitation de débit – des heures d'enquête sur un problème qui ne devrait pas exister.

La limitation du débit sur les points de terminaison sensibles appartient aux règles personnalisées. Les connexions, la récupération de mot de passe et les points de terminaison OTP ont des profils de trafic très différents de ceux du reste de l'application. Une règle limitant /auth/login à 5 requêtes par minute et par IP protège contre le credential stuffing sans affecter aucun autre chemin.

Le blocage des agents utilisateurs de scrapers malveillants s'applique également ici : http.user_agent contains "Scrapy" ou http.user_agent eq "" sont des filtres qu'un ensemble de règles génériques ne mettra pas en œuvre car ils dépendent de votre décision concernant les sources à exclure.

Comment résoudre les faux positifs sans ouvrir de failles

Lorsqu'un ensemble de règles géré ne se déclenche pas correctement, la désactivation de la règle supprime globalement la protection de tous les autres chemins sur lesquels elle fonctionnait. La bonne réponse est une règle Skip dont la portée est précise : http.request.uri.path eq "/api/content" and cf.waf.rule_id eq "100016" désactive la règle 100016 pour ce chemin uniquement, maintenant ainsi la couverture sur l'ensemble de l'application. La définition de la portée par cf.waf.rule_id plutôt que par groupe de règles constitue la différence entre une exception chirurgicale et un trou.

Les identifiants de règle apparaissent dans les journaux d'activité lorsque la règle se déclenche en mode Journal – une autre raison pour laquelle la période d'observation est obligatoire avant tout blocage.

Comment calibrer les plans en fonction de ce qui est disponible

Le plan gratuit propose 5 règles personnalisées et aucun accès aux ensembles de règles gérés. Avec 5 règles, la priorité est claire : liste verte des IP internes, blocage par haut cf.threat_score, limitation de débit sur le endpoint le plus critique. Essayer de tout couvrir avec 5 règles aboutit à des règles trop larges avec des effets secondaires imprévisibles.

Le plan Pro va jusqu'à 20 règles et débloque des ensembles de règles gérés. Le plan Business atteint 100, ce qui vous permet de créer différents profils de protection par groupe de points de terminaison : API publiques avec une limitation de débit plus permissive, des panneaux d'administration avec une inspection plus agressive, des webhooks partenaires avec des listes autorisées par IP source. Avec 20 règles, vous faites des choix ; avec 100 tu fais de la politique.

Le processus d'étalonnage qui fonctionne en pratique

L'ordre des opérations compte plus que la configuration spécifique de chaque règle. Commencer par un blocage actif dans une application de production sans référence de trafic est une recette pour perturber les utilisateurs réels.

La séquence commence avec tous les ensembles de règles gérés en mode Log pendant sept à quatorze jours. Le tableau de bord d'activité WAF accumule des données réelles : quelles règles seraient déclenchées, à quelle fréquence, sur quels chemins. Grâce à ce mappage, vous identifiez les candidats faux positifs avant qu'ils ne se transforment en incidents, écrivez des règles de saut avec la portée correcte et configurez des listes d'autorisation et des règles de blocage personnalisées.

Ce n'est qu'alors qu'il est logique de passer au défi géré ou au blocage, en commençant par les règles présentant le risque de faux positif le plus faible (CVE spécifiques) et en passant aux règles plus larges (OWASP SQLi, OWASP XSS) à mesure que vous gagnez en confiance. Le calibrage du seuil de l'ensemble de règles de base OWASP est la dernière décision, car cela dépend de la répartition réelle des scores dans le trafic de votre application.