ModSecurity et l'OWASP CRS — les règles WAF que nous livrons réellement sur Apache

ModSecurity est l'un de ces outils que presque tout le monde a installé et que presque personne n'a tuné. Le pattern dans les audits est constant : le module est chargé, l'OWASP Core Rule Set est posé avec ses paramètres par défaut, les logs se remplissent de milliers d'alertes que personne ne lit, et soit (a) il tourne tranquillement en DetectionOnly depuis des années, soit (b) il bloque du trafic légitime et le client ne le sait pas.

Les deux modes signifient que le WAF ne fait rien d'utile.

Pourquoi s'embêter en 2026 quand Cloudflare existe ?

Trois raisons pour lesquelles nous déployons encore ModSecurity au niveau origin derrière un cloud WAF :

1. Défense en profondeur. Le cloud WAF est une couche. Quand il se trompe de classification, ou que le client n'a pas activé un pack de règles, ou que quelqu'un découvre l'IP origin, la couche interne attrape ce que l'edge a raté.
2. Règles spécifiques à l'application. Cloudflare ne sait pas que votre endpoint /admin/export ne devrait jamais voir un mot-clé SELECT. ModSecurity à l'origin le peut.
3. Forensique. Le log d'audit ModSecurity vous donne la requête complète qui a déclenché la règle. Les cloud WAFs donnent des données échantillonnées, lossy.

La configuration de base

ModSecurity 3 (libmodsecurity) avec le connector Apache — pas le v2 legacy :

<IfModule security2_module>
    SecRuleEngine On
    SecRequestBodyAccess On
    SecRequestBodyLimit 13107200
    SecAuditEngine RelevantOnly
    SecAuditLogParts ABIJDEFHZ
    Include /etc/modsecurity/crs/crs-setup.conf
    Include /etc/modsecurity/crs/rules/*.conf
</IfModule>

Ensuite, le vrai travail de tuning — choisir le bon paranoia level, allowlister les règles qui se déclenchent sur le trafic normal de votre application, et écrire les règles par route que Cloudflare ne peut pas. L'article Medium complet couvre :

• Paranoia Level 1 → 4 — ce que chacun ajoute, et le niveau que nous livrons par défaut
• Le workflow de « triage des faux positifs » que nous menons pendant deux semaines avant de basculer en mode block
• Règles custom pour les chemins d'application courants (admin, endpoints API, uploads de fichiers)
• Envoyer le log d'audit au SIEM, et les dashboards que nous surveillons
• Les règles que nous désactivons toujours (et pourquoi)

Suite sur Medium.