WAF et filtrage : filet, pas muraille

Prérequis : cours précédent + 2.x.

Pourquoi

Un WAF (pare-feu applicatif : filtre les requêtes HTTP sur signatures/comportements) ne remplace pas le code sûr — mais il achète du temps (patcher sans urgence vitale) et bloque l'opportuniste. Filet, pas muraille.

Concepts

• Modes : détection (log) puis blocage. Toujours monitorer d'abord (comme la CSP : observer avant de couper) : un WAF en blocage direct = faux positifs = clients bloqués.
• Règles : managées (AWS WAF, Cloudflare — mises à jour par l'éditeur) vs CRS OWASP (ModSecurity, à tuner). Par défaut : SQLi/XSS/RFI/LFI/path traversal/proto-pollution patterns.
• Rate limiting : par IP + par user + par endpoint sensible (login !). 429 avec Retry-After, allowlist (bureaux, monitoring), denylist (Tor/exit nodes selon risque).
• Ce que le WAF ne fait PAS : logique métier (IDOR !), auth cassée, secrets exposés. Il filtre des patterns, il ne comprend pas ton app.

Exemple : montée en charge d'un WAF

Semaine 1 : mode détection, revue quotidienne des logs
Semaine 2-3 : activer les règles à 0 faux positif, tuner les autres
Semaine 4 : blocage + rate-limit login (5/min/IP) + alertes

Cas réel

Boutique sous credential stuffing (10k logins/min depuis un botnet) : WAF + rate-limit + challenge (captcha invisible au-delà du seuil) = attaque absorbée sans toucher au code. Sans : base saturée + comptes compromis (réutilisation !).

Pièges

• Blocage direct jour 1 : faux positifs = perte de clients. Détection d'abord, toujours.
• Croire le WAF = sécu : IDOR, broken access, logique — invisibles au WAF. Le code d'abord.
• Jamais tuné (« on a un WAF » coché) : règles par défaut = bruit + trous. Revue mensuelle minimum.

À retenir

Détection puis blocage, managées + tunées, rate-limit partout sensible, WAF ≠ code sûr.