Les pare-feu traditionnels protègent les réseaux. Les pare-feu applicatifs Web (WAF) protègent les applications. Et en 2026, les attaques ne visent plus les ports — elles visent les API, les formulaires, les sessions et les payloads HTTP. L’OWASP Top 10 n’a pas changé de fond depuis des années, mais les DSI continuent de déployer des WAF propriétaires à 30 K€/an qui filtrent mal le trafic légitime et laissent passer les attaques sophistiquées.
Coraza est un WAF open source qui change la donne : compatible ModSecurity, intégré nativement à Traefik, conforme aux règles OWASP Core Rule Set, et 100 % open source. Pas de licence, pas de vendor lock-in, pas de boîte noire.
Ce guide vous explique comment déployer Coraza comme WAF dans votre architecture cloud, en conformité avec NIS2 et DORA.
Pourquoi un WAF en 2026 (et pourquoi Coraza)
Les menaces ne passent plus par le port 22
Les statistiques de l’OWASP sont sans appel :
- 70 % des attaques ciblent la couche applicative (OWASP)
- 95 % des violations de données impliquent des failles applicatives (Verizon DBIR)
- Injection SQL et XSS restent dans le Top 5 depuis 10 ans
- Les API sont le nouveau champ de bataille : 80 % du trafic web est aujourd’hui de l’API
Un pare-feu réseau ne voit pas l’injection SQL dans un paramètre POST. Un VPN ne filtre pas le XSS dans un cookie. Seul un WAF inspecte la couche 7 (HTTP) pour bloquer les attaques applicatives.
Pourquoi Coraza et pas ModSecurity ou un WAF propriétaire
| Critère | ModSecurity | WAF propriétaire | Coraza |
|---|---|---|---|
| Licence | Apache 2.0 (mais lié à Apache) | Propriétaire | Apache 2.0 |
| Intégration | Apache/Nginx seulement | Appliance propriétaire | Traefik, Caddy, Nginx, Go |
| Performance | Modérée (C) | Variable | Élevée (Go) |
| Règles OWASP | Oui, CRS 4.x | Oui, varies | Oui, CRS 4.x |
| Langage | C (legacy) | Propriétaire | Go (moderne) |
| Audit | Code source public | Boîte noire | Code source public |
| Coût | Gratuit | 15-30 K€/an | Gratuit |
Coraza = ModSecurity 2.0. Mêmes règles, même syntaxe SecLang, mais en Go, plus rapide, mieux intégré, et sans les limites de l’architecture C d’Apache.
L’architecture WAF dans un cloud souverain
WAF + Traefik + Zero Trust
Coraza s’intègre nativement à Traefik, le reverse proxy utilisé dans la stack Cloud Inspire :
┌─────────────────────────────────────────────────────┐
│ INTERNET │
└─────────────────────┬───────────────────────────────┘
│ HTTPS
┌─────────────────────▼───────────────────────────────┐
│ TRAEFIK (Reverse Proxy) │
│ + Coraza WAF (Plugin natif) │
│ │
│ • Terminaison TLS │
│ • Filtrage OWASP (930 catégories d'attaque) │
│ • Rate limiting │
│ • Geo-blocking │
│ • Virtual patching │
└──────────┬───────────┬──────────────┬──────────────┘
│ │ │
┌─────▼────┐┌─────▼────┐┌───────▼──────┐
│ App Web ││ API ││ Portail │
│ (Site) ││ (REST) ││ (Citoyen) │
└──────────┘└──────────┘└──────────────┘Avantage : le WAF est dans le proxy, pas devant. Pas de point de défaillance supplémentaire, pas de saut réseau, pas de latence ajoutée.
Les 7 couches de protection
| Couche | Protection | Exemple |
|---|---|---|
| L3/L4 | IP blocking, geo-blocking | Blocage des pays non ciblés |
| L7 - HTTP | Validation des méthodes | BLOQUER PUT, DELETE si non utilisé |
| L7 - Headers | Validation des en-têtes | Anti-clickjacking (X-Frame-Options) |
| L7 - Body | Filtrage du contenu | Injection SQL, XSS dans les formulaires |
| L7 - Session | Protection des sessions | Session fixation, CSRF |
| L7 - Rate | Limitation du débit | 100 req/min par IP (anti-brute force) |
| L7 - Bot | Détection des bots | Challenge JavaScript, CAPTCHA |
Déploiement Coraza : configuration pratique
Configuration de base
Coraza s’intègre à Traefik via un plugin natif. Configuration minimale :
# traefik/traefik.yml (extrait)
experimental:
plugins:
coraza:
moduleName: "github.com/corazawaf/coraza-traefik-plugin"
settings:
directives: |
SecRuleEngine On
SecDefaultAction "phase:1,log,deny,status:403"
# OWASP Core Rule Set
Include @owasp_crs/10-setup.conf
Include @owasp_crs/11-setup.conf
# Règles personnalisées
SecRule REQUEST_URI "@streq /health" "id:1,phase:1,pass,nolog"
# Rate limiting
SecAction "id:2,phase:1,initcol:ip=%{REMOTE_ADDR},pass,nolog"
SecRule IP:COUNT "@gt 100" "id:3,phase:1,deny,status:429,msg:'Rate limit exceeded'"Règles OWASP Core Rule Set (CRS)
Le CRS d’OWASP est le standard de facto pour les WAF. Il couvre les 10 catégories OWASP :
| ID Catégorie | Attaque couverte | Exemple de détection |
|---|---|---|
| 920.x | Protocol violations | Requête HTTP malformée |
| 921.x | Protocol attacks | Request smuggling |
| 930.x | Application attacks | Path traversal (../../etc/passwd) |
| 931.x | Application attacks | Remote file inclusion |
| 932.x | Application attacks | Remote code execution |
| 933.x | Application attacks | PHP injection |
| 941.x | Application attacks | XSS (cross-site scripting) |
| 942.x | Application attacks | SQL injection |
| 943.x | Application attacks | Session fixation |
| 949.x | Inbound blocking | Score d’anomalie cumulé |
Mode recommandé : commencer en détection (mode SecRuleEngine DetectionOnly) pendant 2 semaines, analyser les faux positifs, puis passer en blocage (SecRuleEngine On).
Règles personnalisées sectorielles
Pour le secteur bancaire et financier :
# Banqueroute : bloquer les tentatives d'injection sur les API de paiement
SecRule REQUEST_URI "@contains /api/v1/payment" \
"id:1000,phase:1,pass,nolog,ctl:ruleEngine=On"
# Bloquer les user-agents suspects
SecRule REQUEST_HEADERS:User-Agent "@rx (?i)(sqlmap|nikto|nmap|masscan)" \
"id:1001,phase:1,deny,status:403,msg:'Suspicious user-agent'"
# Protection contre les attaques par force brute sur les endpoints d'auth
SecRule REQUEST_URI "@rx /api/v1/auth" \
"id:1002,phase:1,pass,nolog,initcol:ip=%{REMOTE_ADDR}"
SecRule IP:AUTH_COUNT "@gt 5" \
"id:1003,phase:2,deny,status:429,msg:'Auth rate limit'"WAF et conformité réglementaire
NIS2 : sécurité du réseau et des systèmes
NIS2 (Art. 21) exige des « mesures techniques appropriées » pour la sécurité du réseau. Le WAF répond directement :
| Mesure NIS2 | Réponse WAF |
|---|---|
| Sécurité du réseau | Filtrage L7, protection contre les attaques applicatives |
| Gestion des incidents | Journalisation de toutes les requêtes bloquées |
| Détection des intrusions | OWASP CRS, détection des attaques connues |
| Traçabilité | Audit logging complet des requêtes et blocages |
DORA : résilience des systèmes financiers
DORA exige la résilience opérationnelle des systèmes ICT financiers :
- Protection des API bancaires : Coraza filtre les injections, les attaques par force brute et les tentatives d’extraction de données
- Virtual patching : quand une vulnérabilité est découverte, une règle WAF la bloque pendant que l’équipe corrige le code
- Reporting d’incidents : les logs Coraza alimentent les rapports DORA sur les tentatives d’attaque
RGPD : sécurité des traitements
L’article 32 du RGPD exige des « mesures techniques appropriées » pour protéger les données personnelles :
- Protection contre l’injection : les attaques par injection SQL ciblent souvent les bases de données contenant des données personnelles
- Anti-scraping : les règles de rate limiting empêchent l’extraction massive de données
- Journalisation : les logs d’accès et de blocage servent de preuve de conformité
Les 5 erreurs de configuration WAF
Erreur 1 : Activer en mode blocage immédiatement
Le WAF bloquant du trafic légitime est pire que pas de WAF du tout (les utilisateurs ne peuvent plus travailler).
Solution : 2 semaines en mode DetectionOnly minimum. Analyser les faux positifs. Créer des exceptions. Puis passer en mode blocage.
Erreur 2 : Ne pas personnaliser les règles
Le CRS OWASP est générique. Il bloquera des requêtes légitimes de votre application métier.
Solution : identifier les faux positifs pendant la phase de détection et créer des règles d’exception ciblées.
Erreur 3 : Ignorer les logs
Un WAF qui journalise mais que personne ne lit est un WAF inutile.
Solution : intégrer les logs Coraza dans Loki (via Promtail). Dashboard Grafana dédié avec alertes sur les pics d’attaques.
Erreur 4 : Protéger seulement le site web
Les API sont le vecteur d’attaque n°1 en 2026. Si vous ne protégez que le site web et pas les API, vous protégez la porte d’entrée mais laissez les fenêtres ouvertes.
Solution : règles WAF spécifiques pour chaque endpoint API (authentification, paiement, données personnelles).
Erreur 5 : Pas de virtual patching
Quand une CVE est publiée, il faut parfois des semaines pour corriger le code. Pendant ce temps, votre application est vulnérable.
Solution : ajouter une règle WAF temporaire qui bloque l’exploit spécifique. C’est le virtual patching — une protection immédiate pendant que l’équipe corrige le code.
Observabilité du WAF : dashboards et alertes
Dashboard Coraza dans Grafana
Les métriques essentielles à surveiller :
| Métrique | Seuil d’alerte | Action |
|---|---|---|
| Requêtes bloquées/min | > 50 | Investigation attaque |
| Requêtes bloquées/heure | > 500 | Attaque probable |
| Top règle bloquante | Tendance | Ajuster les règles |
| Taux de faux positifs | > 5 % | Créer des exceptions |
| Score d’anomalie moyen | > 3 | Revoir la configuration |
| Tentatives d’injection SQL | > 10/heure | Alerte sécurité |
Intégration avec la stack d’observabilité
Coraza → Traefik logs → Promtail → Loki → Grafana
│
├── Dashboard WAF (temps réel)
├── Alertes (Attack > seuil)
└── Rapport mensuel NIS2/DORAChaque requête bloquée est journalisée avec :
- L’IP source
- L’URL cible
- La règle qui a déclenché le blocage
- Le score d’anomalie
- Le payload complet (pour analyse forensique)
La stack Coraza Cloud Inspire
| Composant | Outil | Rôle |
|---|---|---|
| WAF | Coraza | Filtrage applicatif L7, OWASP CRS |
| Reverse proxy | Traefik | Terminaison TLS, routage, intégration WAF |
| Identité | Keycloak | Authentification, MFA, SSO |
| Supervision | Grafana + Loki | Dashboards WAF, alertes, audit trail |
| Secrets | Vault | Certificats TLS, rotation automatique |
| Réseau | Cilium | Micro-segmentation, NetworkPolicy |
Tout est open source. Pas de licence propriétaire, pas de boîte noire, pas de vendor lock-in sur votre sécurité applicative.
Performance : Coraza vs ModSecurity vs WAF propriétaire
| Métrique | ModSecurity | WAF propriétaire | Coraza |
|---|---|---|---|
| Latence ajoutée | 15-25 ms | 5-15 ms | 3-8 ms |
| Débit (req/s) | 2 000 | 5 000 | 10 000+ |
| CPU overhead | Élevé (C) | Variable | Faible (Go) |
| Mémoire | Élevée | Variable | Optimisée |
| Règles OWASP CRS | 800+ | Variable | 800+ |
| Faux positifs | Modérés | Variables | Configurables |
Coraza écrit en Go est 3-5x plus rapide que ModSecurity en C, avec une empreinte mémoire réduite. Pas de process séparé, pas de communication inter-process — le WAF tourne dans le même processus que Traefik.
Déploiement en 5 jours
| Jour | Action | Livrable |
|---|---|---|
| J1 | Installer Coraza + Traefik | WAF opérationnel en mode détection |
| J2 | Configurer OWASP CRS + règles personnalisées | 800+ règles actives |
| J3 | Phase de détection (2 semaines recommandées) | Liste des faux positifs |
| J4 | Ajuster les exceptions + passer en blocage | WAF en production |
| J5 | Intégrer Grafana + alertes | Dashboard WAF opérationnel |
Note : la phase de détection (J3) dure idéalement 2 semaines en production pour collecter assez de trafic légitime. Le déploiement technique prend 5 jours, la mise en production complète 3 semaines.
Conclusion
Le WAF est la dernière ligne de défense de vos applications — et il doit être ouvert, auditable et performant. Coraza apporte tout ce que les WAF propriétaires offrent (règles OWASP, virtual patching, rate limiting), sans le coût, sans la boîte noire, et sans le lock-in.
Pour les DSI en environnement réglementé, Coraza + Traefik est la combinaison qui sécurise les applications tout en satisfaisant les exigences NIS2, DORA et RGPD de journalisation et de traçabilité.
Cloud Inspire déploie Coraza + Traefik en 5 jours sur votre cloud privé OpenNebula, avec les dashboards Grafana et les règles OWASP préconfigurées. Si vous voulez sécuriser vos applications sans payer un WAF propriétaire 30 K€/an, parlons-en.