Glossaire · Architecture cybersécurité WAF (Web Application Firewall)
Couche de sécurité qui inspecte le trafic HTTP/HTTPS entrant et sortant des applications web, bloquant les attaques comme l'injection SQL, le XSS et les exploits du Top 10 OWASP avant qu'ils n'atteignent le serveur d'origine. Livrée soit en tant que service reverse-proxy (Cloudflare, AWS WAF), soit en tant qu'agent à l'origine (CrowdSec, ModSecurity, HAProxy).
## Ce que fait réellement un WAF
Un Web Application Firewall inspecte les requêtes et réponses HTTP/HTTPS transitant entre un client et une application web, en appliquant des règles qui identifient et bloquent les attaques qu'un pare-feu de couche réseau (qui ne voit que les informations IP/port) ne peut reconnaître. Les catégories canoniques d'attaques couvertes :
- **Injection SQL** — entrée malveillante ciblant la couche base de données
- **Cross-site scripting (XSS)** — injection de script côté client dans les pages servies à d'autres utilisateurs
- **Cross-site request forgery (CSRF)** — piéger des utilisateurs authentifiés pour effectuer des actions non désirées
- **Server-side request forgery (SSRF)** — forcer le serveur à effectuer des requêtes vers des URL contrôlées par l'attaquant
- **XML External Entity (XXE)** — abus des parseurs XML pour exfiltrer des données
- **Path traversal** — accès à des fichiers en dehors du répertoire prévu
- **Injection de commandes** — passage de métacaractères shell aux appels système
- **Attaques par téléchargement de fichiers** — fichiers malveillants déguisés en téléchargements légitimes
- **Contournement d'authentification et failles de gestion de session**
- **Abus de logique métier** — usages abusifs spécifiques à l'application (endpoints avec rate-limit, abus de codes promo, credential stuffing)
Le jeu de règles de référence pour la plupart des WAF est le **OWASP Core Rule Set (CRS)**, une bibliothèque open source de règles de détection basées sur des motifs, maintenue par la Fondation OWASP.
## Deux architectures de déploiement
Les WAF se présentent sous deux architectures fondamentalement différentes — et ce choix a des implications structurelles de souveraineté.
### WAF reverse-proxy (hébergé dans le cloud)
Le trafic est d'abord routé vers le réseau edge du fournisseur. Le fournisseur inspecte, filtre et (si légitime) transfère à l'origine. Exemples :
- **Cloudflare WAF** (États-Unis, Delaware, NYSE : NET)
- **AWS WAF** (États-Unis, Delaware, Nasdaq : AMZN)
- **Akamai Kona** (États-Unis, Nasdaq : AKAM)
- **Fastly Next-Gen WAF** (États-Unis, NYSE : FSLY)
- **Bunny.net Shield** (Slovénie, contrôlé par l'UE)
Le modèle reverse-proxy confère au fournisseur un pouvoir énorme (absorption DDoS à l'échelle du Tbps, CDN mondial, edge compute) mais achemine le trafic client via l'infrastructure du fournisseur — ce qui devient une exposition juridictionnelle si le fournisseur a une maison mère américaine.
### WAF basé sur agent (self-hosted ou on-origin)
Un agent s'exécute sur le serveur d'origine (ou en frontal comme composant inline), inspectant le trafic sans le router via un service externe. Exemples :
- **CrowdSec AppSec Component** (France, licence MIT)
- **ModSecurity** (open source, historiquement la référence)
- **Coraza** (successeur ModSecurity basé sur Go)
- **HAProxy Enterprise WAF**
- **NGINX App Protect**
- **AWS-shield agent-modes**
Les WAF basés sur agent gardent le trafic client sur votre propre infrastructure. Le fournisseur voit les mises à jour de règles et les agrégats de télémétrie, pas le flux brut de requêtes.
## Implications de souveraineté
Sous le modèle reverse-proxy, le trafic client — y compris les corps de requête contenant des données personnelles, des informations de paiement, des credentials d'authentification et des tokens API — traverse l'infrastructure du fournisseur WAF. Pour un fournisseur à maison mère américaine, ce flux est exposé à la portée du CLOUD Act et de la Section 702 du FISA :
- Cloudflare, AWS WAF, Fastly, Akamai — la maison mère est constituée aux États-Unis.
- Au titre du CLOUD Act, les autorités américaines peuvent contraindre le fournisseur à divulguer les données qu'il traite, y compris les requêtes en cours de clients UE.
Pour les organisations européennes opérant dans des secteurs réglementés — banque, santé, administration publique, défense — router le trafic client via un WAF de type société Delaware est souvent une exposition de conformité qui nécessite soit une alternative reverse-proxy à maison mère UE (Bunny.net Shield), soit une architecture basée sur agent (CrowdSec + un CDN européen).
## Le modèle CrowdSec + Bunny.net
Un modèle courant de remplacement souverain européen pour l'offre combinée WAF + CDN + DDoS de Cloudflare :
1. **CrowdSec** (SAS de Paris, open source MIT, basé sur agent) gère WAF + gestion de bots + réputation IP — s'exécutant sur vos serveurs, sans intermédiaire de société américaine.
2. **Bunny.net** (Slovénie) gère le cache edge CDN et le shielding d'origine sous juridiction UE.
3. Optionnel : **OVHcloud Anti-DDoS** ou **Bunny Shield** gère le scrubbing DDoS volumétrique de couche réseau.
La pile combinée remplace la surface fonctionnelle utile de Cloudflare tout en gardant le trafic sous garde de juridiction UE à chaque saut.
## Implications NIS2 et DORA
- **NIS2** : les entités essentielles et importantes doivent documenter les contrôles de sécurité, y compris l'architecture WAF. Pour les entités proches du secteur public, la juridiction du fournisseur WAF devient de plus en plus une considération documentée.
- **DORA** : les tests de résilience opérationnelle pour les services financiers exigent des tests d'intrusion pilotés par la menace qui couvrent la surface d'attaque externe — y compris la couche WAF. Les tests doivent inclure des scénarios adversariaux réalistes ; si le fournisseur WAF lui-même se trouve dans une juridiction où une portée réglementaire pourrait être contrainte, c'est un facteur de risque opérationnel.
## WAF gratuits / open source
Pour les équipes souhaitant une véritable capacité WAF open source :
- **ModSecurity** — la référence historique, passée de la maintenance Trustwave à la maintenance OWASP en 2024. Solide mais v3 a annoncé sa fin de vie.
- **Coraza** — le successeur moderne basé sur Go recommandé par OWASP pour les nouveaux déploiements.
- **CrowdSec AppSec Component** — sous licence MIT, s'intègre à la blocklist crowdsourcée et au Security Engine de CrowdSec.
Pour la plupart des équipes européennes construisant une infrastructure souveraine, la combinaison de Coraza (ou CrowdSec AppSec) en périphérie applicative + CrowdSec Security Engine surveillant les journaux + Bunny.net pour le CDN offre une pile WAF entièrement open source et de juridiction UE à faible coût.
Cela vous a-t-il été utile ?
Merci pour votre retour !