Web Application Firewall et protection contre les attaques

Résumé succinct

WAF/WAAP filtre et surveille le trafic HTTP (S )/WebSocket au niveau de l'application : bloque l'exploitation des vulnérabilités (OWASP Top 10), tente de contourner l'authentification, scanne, bot-traffic automatisé et L7 DDoS. La pile moderne est complétée par un moteur anti-bot, une protection API, une limitation des taux, des patchs virtuels et une intégration étroite avec CI/CD pour que les règles soient aussi sûres que le code.

Rôles et place dans l'architecture

WAF Edge/CDN (cloud) : faible latence, réputation globale/règles gérées, L7 DDoS.
Auto-hébergé WAF (on-bou/K8s) : intégration profonde avec les réseaux internes, réglage fin.
Approche WAAP : Fonction WAF + API-Gateway (schema-validation, authZ), anti-bot, L7 DoS, mTLS.
Schémas d'activation : Reverse-proxy avant l'application ; Ingress-controller en K8s ; Filtres Service Mesh ; sidecar.

Modèle de protection

Sécurité negative (signatures/CRS) : couverture rapide des techniques connues (SQLi/XSS/SSRF/RCE).
Sécurité positive (allow-list) : nous ne résolvons que les requêtes « valides » (méthodes/chemins/schémas/types de contenu).
Patching virtuel : verrouillage en ligne de l'exploit jusqu'à la fixation du code.
Contextualité : différentes politiques pour le contenu statique, API, amiraux, téléchargements, webhooks.

Types de menaces et mesures

OWASP Top 10 : SQLi, XSS, IDOR/BOLA, SSRF, injections dans les gabarits, désérialisation, misconfigues.
L7 DDoS : demandes lentes/titres, burst sur les endpoints chauds → protection : rate-limits, challenge, auto-block.
Bots/scrapers : comportement, fréquence, modèles « non humains », device-fingerprinting, tokens dynamiques.
Credential Stuffing/ATO : interception/excès de logins → anomalie par IP/ASN, règles de velocity, facteurs de dopage.
Téléchargements : type/taille/multiscan par antivirus, « image-only » dans les médias.
API/GraphQL : schema-validation, 'maxDepth '/' maxCost', interdiction de la wildcard non définie, contrôle des méthodes et des en-têtes.

Stratégies et concepteurs de règles

Squelette de base pour toute application :

1. Transport : TLS 1. 2+/1. 3, HSTS, mTLS sur les backends sensibles.

2. Les méthodes : allow-list ('GET, POST, PUT, DELETE, PATCH, OPTIONS') sont uniques par ressource.

3. Voies : masques stricts/regexts ; adminka/facturation - par préfixe/domaine distinct.

4. Titres : listes blanches, interdiction de dangereux (« X-Original-URL », non standard) sans besoin.

5. Corps : JSON-only/Multipart-only le long de l'itinéraire ; limites 'Content-Length', bloc de binaires par 'login/search'.

6. Limites de taux : per-IP/ASN/clé/organisation ; des limites distinctes pour les demandes « coûteuses ».

7. Anti-bot : scoring comportemental, challenges « non irritants », scrabble identitaire (cookies tokens, JA3/TLS FP).

8. CRS/Règles gérées : inclus, tuning sous FP.

9. Wirt patchs : verrouillage rapide des paramètres/modèles d'attaque connus.

10. Logs/métriques : format unique, corrélation avec 'trace _ id', rapports FP/TP.

Pratique du tuning : comment réduire les faux positifs

Exécutez de nouvelles règles dans Detect-only/Count-mode (shadow) avec un échantillon de trafic.
Créer des exceptions par contexte ('path =/search', 'param = q' autoriser les symboles spéciaux).
Diviser la zone : « pages publiques » vs « opérations sensibles » (le seuil d'agressivité est différent).
Convoyeur : règle de → stajing → canari (1-5 %) → prod ; rollback par métriques FP.
Maintenir un catalogue de « faux » payload pour les tests de régression.

Intégration dans DevSecOps

CI : règles statiques en Git ; tests : repliement des requêtes réelles + synthétiques du catalogue d'attaques.
CD : Canaries, drapeaux de fiches ; suivi « politique » (modification des règles = changement).
RASP et SAST/DAST : WAF complète mais ne remplace pas la correction de code.

Observabilité et SLO

Métriques :

p95/99 de latence via WAF ; la proportion de personnes bloquées/ignorées ; share Managed Rules vs custom; «attack rate».
Anti-bot : proportion de challenges/passes, FP/TP.
L7 DDoS: burst-rate, auto-mitigation events.

Exemples de SLO :

"Pas plus de 0. 5 % FP pour les opérations autorisées/24 heures ".
«p95 overhead WAF ≤ 10 мс».
« TTR du patch virtuel ≤ 30 minutes ».
Alarma : sursaut de 4xx/5xx après la publication des règles ; la croissance du PF ; La chute du passage du capch ; dégradation de la validation JWKS/mTLS.

Exemples de configurations

ModSecurity + OWASP CRS (Nginx)

nginx
Enabling ModSecurity modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main. conf;

`/etc/nginx/modsec/main. conf`:

apache
SecRuleEngine On
Include /usr/local/owasp-modsecurity-crs/crs-setup. conf
Include /usr/local/owasp-modsecurity-crs/rules/.conf

Example of an exception for a search parameter
SecRule REQUEST_URI "@beginsWith /search" "id:900100,phase:1,pass,nolog,ctl:ruleRemoveByTag=attack-xss"
SecRule REQUEST_URI "@beginsWith /search" "id:900101,phase:2,pass,ctl:ruleRemoveTargetById=942100; ARGS:q"

AWS WAF (JSON, rate limit + bloc liste des pays)

json
{
"Name": "prod-web-acl",
"Scope": "CLOUDFRONT",
"DefaultAction": { "Allow": {} },
"Rules": [
{
"Name": "BurstLogin",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": { "ByteMatchStatement": {
"SearchString": "/login",
"FieldToMatch": { "UriPath": {} },
"TextTransformations": [{ "Priority": 0, "Type": "NONE" }],
"PositionalConstraint": "CONTAINS"
}}
}
},
"Action": { "Block": {} },
"VisibilityConfig": { "MetricName": "BurstLogin", "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true }
}
]
}

Cloudflare (Expression Rules)


(http. request. uri. path contains "/admin" and ip. geoip. country ne "UA")
or (http. request. uri. path eq "/login" and cf. threat_score > 10)
or (http. request. uri. path contains "/api" and not http. request. headers["authorization"][0] contains "Bearer ")

NGINX : une règle simple sur les méthodes/corps

nginx location /api/withdraw {
limit_except POST { deny all; }
if ($request_method = POST) {
set $cl $http_content_length;
if ($ cl = "") {return 411;} # length is required if ($ cl> 1048576) {return 413;} # ≤ 1MB add_header X-Idempotency-Required "true";
}
}

GraphQL : Limiteurs

'maxDepth = 6', 'maxCost = 1000', interdiction de '__ schema' dans la vente, liste des opérations, validation des titres ('Content-Type : application/json').

Anti-bot et contrôles homme-amis

Défi invisible (challenges JS sans captcha), proof-of-work sur les voies « chères », analyse comportementale (mouvements/temps).
TLS/JA3-fingerprinting, réputation IP/ASN, listes proxy/VPN (dans des limites raisonnables).
Pièges (champs honeypot) sur les formes, jetons dynamiques de forme/session.
Protection de la vie privée : minimisation du tracking, politiques transparentes, options opt-out.

focus API

Schema-first : OpenAPI/JSON Schema pour la validation ; interdiction des champs superflus.
Auth : nécessairement Bearer JWT ou mTLS ; reject без `Authorization`.
Rate/Quota: per-key/per-org; en cas de dépassement - « soft block « /slowing.
Webhooks : signature HMAC, 'timestamp + nonce', fenêtre de réception courte.
GraphQL : voir limiteurs ci-dessus ; Loger le nom/l'étiquette de l'opération.

Téléchargements et médias

Limite de taille, whitelists MIME/extensions, renommer les fichiers ;

Scan AV (multi-moteurs), politique ImageMagick (sans décodeurs dangereux) ;

Service thumb sur un domaine distinct, serve-only-images.

Sécurité des amiraux et des zones critiques

Domaine/chemin séparé, mTLS/interdiction avec ASN/pays partagés, limites de taux rigides, accès JIT, IP allow-list.
Des signaux supplémentaires (device posture, score de risque) → exiger une deuxième vérification.

Opérations, incidents et patchs virtuels

Runbook : libération rapide de la règle de bloc, restriction TTL, notification des commandes.
Critères de retrait : hauteur 4xx/5xx> seuil, FP> seuil, p95 latency↑.
Post-mortem : ajout d'un test à un jeu de règles de régression, fixation d'un alert SIGMA dans SIEM.

Conformité et vie privée

Loger le minimum : chemin/méthode/code/cause du bloc/identifiants ; ne pas garder de PII/secrets corporels.
Durée de conservation des logs de stratégie ; accès - par rôle ; cryptage sur disque.

Caractéristiques pour iGaming/fintech

Paiements/décaissements/portefeuilles : quotas per-org, mTLS à PSP, listes d'accès rigoureuses, HMAC pour les webhooks PSP.
ATO/bonus-abyse : règles de velocity sur les logins/enregistrements/codes promotionnels, limites comportementales et anti-bot.
Fournisseurs de contenu/studios : domaines/politiques individuels, IP/ASN allow-list, surveillance Time-to-Wallet/conversions sur l'impact du WAF.
Exigences régionales : géo-politiques (pays/régions), transparence des traitements pour le RGPD.

Feuille de route pour la mise en œuvre

1. Inventaire des zones (public, API, administration, téléchargements).
2. Profil de base : TLS, méthodes/chemins allow-list, règles managées/CRS.
3. Taux limites + anti-bot sur les voies sensibles.
4. Patchs virtuels et processus de règles urgentes (SLA ≤ 30 min).
5. CI/CD pour les règles, stajing/canari/shadow-mode.
6. Télémétrie, SLO, tests de régression des règles.
7. Examen périodique des exceptions et « nettoyage » des contournements.

Erreurs typiques

« Tous les CRS ont été inclus au maximum » → avalanche FP et l'épuisement des équipes.
Règles sans canaries et mode shadow.
L'absence de segmentation : une politique pour tout.
Ignorer l'API/GraphQL de la spécificité (schema/limits).
Logs sans corrélation ('trace _ id') et sans métriques de qualité.

FAQ

WAF remplace-t-il le code sécurisé ?
Non. C'est une couche d'atténuation et un « patch virtuel », mais la dette technique dans le code doit être éliminée.

Comment comprendre qu'il est temps d'allumer les blocs durs ?
Lorsque le rapport de mode shadow montre un FP faible et qu'il y a des tests de régression des règles.

Ai-je besoin d'un WAF distinct pour l'API ?
Mieux vaut WAAP/intégration avec la passerelle API : schéma, limites, authentification, signatures Web.

Résultat

Un WAF/WAAP efficace est une combinaison de CRS/Règles gérées de base, un modèle positif, un anti-bot, des limites et des patchs virtuels, étayés par des processus DevSecOps, une télémétrie et un SLO clair. Cette approche permet une réponse rapide aux vulnérabilités, une résistance aux attaques automatisées et un impact prévisible sur l'UX et les performances.