WAF et protection anti-DDoS : comment protéger vos applications web

Votre application ne tombe pas parce que les attaquants sont des génies. Elle tombe parce qu'un botnet loué pour le prix d'une pizza a pointé quelques millions de requêtes par seconde vers votre endpoint de connexion, et que personne n'avait décidé à l'avance de ce qu'il fallait rejeter. Un WAF et une stratégie anti-DDoS, c'est précisément cette décision : écrite noir sur blanc, et appliquée en périphérie avant que le trafic ne touche votre serveur d'origine.

Savoir ce qui vous frappe réellement

Le « DDoS » n'est pas une attaque. C'en est au moins trois, qui vivent à des couches différentes et appellent des réponses différentes.

Volumétrique (L3/L4). Floods UDP, amplification DNS et NTP, floods SYN. L'objectif : saturer votre lien réseau ou épuiser l'état de connexion de votre load balancer. Les attaques par amplification sont redoutables parce que l'attaquant envoie un petit paquet et qu'un réflecteur mal configuré vous renvoie une réponse des dizaines de fois plus grosse. Vous ne pouvez pas absorber cela au niveau de votre origine. Si le flood dépasse votre lien montant, aucune règle de pare-feu sur votre machine ne vous sauvera : les paquets sont déjà arrivés. La seule vraie réponse, c'est une capacité qui n'est pas la vôtre, autrement dit un réseau anycast ou un prestataire de scrubbing qui absorbe le flood en amont.

Épuisement protocolaire et de l'état. Floods SYN qui remplissent les tables de connexion, abus de renégociation TLS, attaques de type Slowloris qui ouvrent des connexions et les alimentent octet par octet. Ces attaques n'exigent presque aucune bande passante. Un simple VPS peut maintenir des milliers de sockets ouvertes face à une configuration nginx par défaut. Les correctifs sont d'ordre protocolaire : SYN cookies, timeouts agressifs, limites de connexions par source, et terminaison TLS sur une couche edge conçue pour cela.

Couche applicative (L7). Des floods HTTP qui ressemblent à de vrais utilisateurs. Rafales de GET sur votre endpoint le plus coûteux (recherche, export PDF, tout ce qui multiplie les requêtes en base), floods de POST sur le login, credential stuffing, requêtes de cache busting avec des query strings aléatoires pour que chaque hit contourne le CDN et atterrisse sur votre origine. C'est en L7 que se produisent la plupart des dégâts aujourd'hui : c'est bon marché, difficile à distinguer du trafic légitime, et cela vise votre chemin de code le plus lent, pas votre bande passante. C'est le territoire du WAF.

Le cadre de décision est simple : les attaques volumétriques se règlent avec le réseau de quelqu'un d'autre, les attaques protocolaires avec une terminaison en edge et des réglages noyau, les attaques L7 avec des règles, du rate limiting et de la détection de bots. La plupart des équipes ne pensent qu'à la troisième catégorie, et tombent sous la première.

Ce qu'un WAF fait vraiment

Un pare-feu applicatif web est un reverse proxy qui évalue chaque requête HTTP contre un moteur de règles avant de la transmettre. C'est tout le principe. La valeur tient entièrement aux règles, à l'endroit où elles s'exécutent, et à la façon dont vous les opérez.

Règles managées : votre socle, pas votre stratégie

Toute plateforme sérieuse fournit des jeux de règles managés : Cloudflare Managed Rules, AWS Managed Rules, et l'OWASP Core Rule Set (CRS) open source pour ModSecurity et son successeur moderne Coraza. Ils couvrent la couche « produits de masse » : motifs d'injection SQL, payloads XSS, path traversal, signatures de CVE connues, empreintes de scanners.

Deux points comptent au quotidien. Premièrement, le CRS fonctionne par notation d'anomalies : chaque règle déclenchée ajoute des points, et la requête n'est bloquée que lorsque le total franchit un seuil. C'est bien plus tolérant vis-à-vis du trafic réel qu'une correspondance binaire, et le niveau de paranoïa pilote ce compromis. Le niveau 1 est sûr presque partout ; à partir du niveau 3, des corps JSON parfaitement légitimes seront signalés et un vrai travail de réglage s'impose. Deuxièmement, les règles managées protègent contre des formes d'attaque connues, pas contre votre logique métier. Aucune règle managée ne sait qu'un utilisateur ne devrait pas pouvoir valider un panier avec une quantité négative ou énumérer des numéros de facture. Cette couche est traitée dans notre article sur les bonnes pratiques de sécurité des API, et sa place est dans votre application, pas dans le WAF.

Règles personnalisées : là où se jouent les vrais gains

Les règles WAF les plus rentables que nous écrivons pour nos clients sont ennuyeuses et spécifiques :

• Bloquez les requêtes vers /wp-login.php et /xmlrpc.php sur les applications qui ne sont pas des WordPress. Cela seul peut réduire drastiquement le bruit.
• Restreignez les interfaces d'administration par ASN, pays ou mTLS, plutôt que d'espérer que le mot de passe tienne. Ne faites jamais confiance à la seule localisation réseau ; vérifiez l'identité à chaque requête. Et si vous géo-restreignez, documentez-le : pour une entreprise qui sert le marché européen, limiter l'admin à quelques pays est souvent défendable et très efficace.
• Imposez les types de contenu : une API qui ne parle que JSON doit rejeter le multipart/form-data dès la périphérie.
• Soumettez à un challenge, ou bloquez, les requêtes sans Accept-Language, avec des versions TLS antédiluviennes, ou dont l'empreinte JA4 correspond à un outillage de bot connu. Le fingerprinting TLS est discrètement l'un des signaux les plus solides qui existent : imiter la pile TLS d'un navigateur est bien plus difficile que falsifier un User-Agent.

Une règle personnalisée Cloudflare s'exprime ainsi :

(http.request.uri.path contains "/admin"
  and not ip.geoip.asnum in {13335 16509}
  and not cf.bot_management.verified_bot)

Lisible, versionnable, testable. Traitez ces expressions comme du code : pull requests, revue, staging d'abord.

Modèle de sécurité positif ou négatif

Modèle négatif : tout autoriser, bloquer le connu-malveillant. Ce sont les règles managées. Modèle positif : définir exactement ce qui est permis (méthodes, chemins, types de paramètres, schémas de corps) et rejeter tout le reste. Les modèles positifs sont radicalement plus solides et radicalement plus coûteux à maintenir, parce que chaque évolution produit devient une évolution du WAF. Le compromis pragmatique : un modèle négatif en global, et une validation positive par schéma uniquement sur vos surfaces les plus sensibles, comme l'authentification, les paiements et les webhooks. Si vous publiez déjà une spécification OpenAPI, des outils savent la compiler en règles de validation, ce qui transforme votre contrat d'API en frontière d'application.

Le rate limiting : le contrôle le plus sous-estimé

La plupart des incidents L7 que nous voyons n'ont rien d'exotique. C'est un endpoint qui reçoit 200 fois son trafic habituel. Le rate limiting règle cela, à condition de choisir la bonne clé.

• Clé par IP pour les surfaces anonymes. Peu coûteux, mais faible face aux attaques distribuées, et injuste pour les utilisateurs derrière du NAT opérateur (carrier-grade NAT), très répandu au Maghreb et en Afrique francophone, et de plus en plus courant sur les réseaux mobiles européens. Des milliers d'utilisateurs réels peuvent partager une même IP.
• Clé par session ou jeton d'API pour les surfaces authentifiées. Précis, et cela survit à la rotation d'IP.
• Clé par cible pour des cas comme le login : limitez les tentatives par compte, pas seulement par source, sans quoi une campagne de credential stuffing distribuée passera tranquillement sous votre limite par IP.

Fixez les seuils à partir de données, pas au doigt mouillé : mesurez le p99 de votre trafic légitime par clé sur une semaine, puis placez la limite à un multiple confortable. Côté origine, nginx offre une solide dernière ligne de défense :

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;

location /api/auth/ {
    limit_req zone=login burst=10 nodelay;
    limit_req_status 429;
}

Et dans AWS WAF, une règle de débit ciblée maintient le flood entièrement à l'écart de l'origine :

statement {
  rate_based_statement {
    limit              = 300
    aggregate_key_type = "IP"
    scope_down_statement {
      byte_match_statement {
        search_string         = "/api/auth"
        positional_constraint = "STARTS_WITH"
        field_to_match { uri_path {} }
        text_transformation {
          priority = 0
          type     = "LOWERCASE"
        }
      }
    }
  }
}

Renvoyez un 429 avec un en-tête Retry-After, et assurez-vous que votre propre frontend et vos clients mobiles le respectent. D'expérience, la première victime d'un nouveau rate limit est généralement la boucle de retry de votre propre équipe.

Les modes de défaillance qui font vraiment mal

Les dispositifs WAF et anti-DDoS échouent de manière prévisible. Concevez contre ces scénarios dès le premier jour.

Origine exposée. Vous avez placé Cloudflare en frontal, mais votre origine répond toujours à quiconque retrouve son IP via l'historique DNS, les journaux de certificate transparency ou Shodan. L'attaquant contourne toute votre périphérie. Correctif : filtrez l'origine pour n'accepter que le trafic issu des plages d'IP publiées par votre fournisseur edge, activez les authenticated origin pulls (mTLS entre l'edge et l'origine), et changez l'IP d'origine après activation de la protection, car les données DNS historiques survivent à votre migration.

Floods de cache busting. Les attaquants ajoutent des query strings aléatoires pour que chaque requête rate le cache. Correctif : normalisez les clés de cache pour ignorer les paramètres inconnus, et si votre plateforme le permet, appliquez un rate limit spécifiquement sur les cache miss.

Faux positifs bloquants. Une mise à jour de règles managées se met à bloquer votre fournisseur de webhooks ou le proxy de votre plus gros client. Correctif : ne déployez jamais une règle directement en mode blocage. Faites tourner les nouvelles règles en mode comptage ou journalisation pendant au moins une semaine, examinez ce qu'elles auraient bloqué, puis promouvez-les. Gardez un mécanisme d'allowlist d'urgence applicable en minutes, pas en heures.

Le WAF comme doudou sécuritaire. Un WAF filtre des motifs de requêtes. Il ne corrige ni un IDOR, ni un parcours d'authentification cassé, ni une faille de logique métier, et un attaquant compétent saura encoder, fragmenter et muter ses payloads pour contourner des règles par signature. Seuls des tests offensifs réguliers vous diront si vous avez une couverture ou un décor ; voyez notre introduction aux tests d'intrusion pour bien cadrer l'exercice.

Le mode blocage pendant un incident que vous ne voyez pas. Si vos seuls journaux WAF vivent dans un tableau de bord que vous n'ouvrez jamais, vous ne réglerez rien et ne ferez confiance à rien. Envoyez les journaux WAF dans le même pipeline que vos logs applicatifs, avec l'identifiant de règle, l'action et le champ déclencheur sur chaque événement. Et souvenez-vous que ces journaux contiennent des adresses IP, donc des données personnelles au sens du RGPD : fixez une durée de conservation, inscrivez le traitement à votre registre, et votre DPO dormira mieux.

Choisir votre stack

Il n'existe pas de réponse universelle, mais il existe un défaut défendable pour la plupart des équipes produit.

• Cloudflare (offre Pro ou Business et au-delà). Absorption DDoS anycast incluse, règles managées solides, règles personnalisées expressives, scoring de bots et rate limiting au même endroit. Le choix par défaut de la plupart des SaaS et plateformes de contenu, et le chemin le plus rapide de zéro à protégé.
• AWS WAF avec CloudFront et Shield. Le bon choix quand vous êtes déjà profondément dans AWS, que vous voulez de l'infrastructure as code dès le premier jour, et que les décisions WAF doivent cohabiter avec ALB et API Gateway. Plus d'assemblage à prévoir, et un coût qui grimpe avec les règles et les requêtes : surveillez la facture.
• Fastly et son Next-Gen WAF (ex Signal Sciences). Excellent quand vous avez besoin de logique edge avancée en VCL ou Compute et d'une détection L7 pointue avec peu de faux positifs.
• Coraza ou ModSecurity auto-hébergé avec le CRS. Contrôle total, aucune facturation à la requête, et la seule option pour certains environnements réglementés, souverains ou isolés : exigences de localisation des données en Europe, référentiels type SecNumCloud, secteurs sous supervision. Mais le réglage, les mises à jour et le passage à l'échelle sont à votre charge, et vous n'avez aucune protection volumétrique : un WAF auto-hébergé derrière un lien saturé ne protège rien.

Le compromis, dit honnêtement : les plateformes edge managées échangent un peu de contrôle et un abonnement récurrent contre une capacité d'absorption que vous ne pouvez pas construire vous-même. En dessous d'une échelle réellement « grand compte », cet échange vaut presque toujours la peine.

Checklist de déploiement : de l'origine à nu à l'edge défendu

1. Inventoriez votre surface publique : chaque domaine, sous-domaine, API et URL de callback tierce. Les attaquants énumèrent ; faites-en autant.
2. Placez l'edge en frontal : migrez le DNS chez votre fournisseur, activez le proxying, et vérifiez le TLS de bout en bout.
3. Verrouillez l'origine : restreignez le trafic entrant aux plages d'IP de l'edge, activez les authenticated origin pulls, puis changez l'IP d'origine.
4. Activez les règles managées en mode comptage. Laissez-les observer le trafic de production pendant une à deux semaines.
5. Passez en revue les blocages potentiels, ajoutez des exceptions ciblées, puis basculez en mode blocage un jeu de règles à la fois.
6. Ajoutez des rate limits sur l'authentification, la recherche, le paiement et tout endpoint qui déclenche des requêtes coûteuses, avec les clés décrites plus haut.
7. Écrivez deux ou trois règles personnalisées pour votre trafic parasite connu : chemins de CMS fantômes, géo-restriction de l'admin, contrôle des types de contenu.
8. Branchez les journaux WAF et les métriques edge (requêtes bloquées, taux de challenges, taux d'erreurs à l'origine, ratio de cache hit) sur votre stack d'observabilité, avec des alertes sur les variations brutales.
9. Faites vos tests de charge à travers l'edge, pas en le contournant, pour vérifier que vos limites se déclenchent correctement sous pression.
10. Rédigez le runbook : qui peut activer le mode « sous attaque », qui peut pousser une règle d'urgence, et à quoi ressemble l'escalade vers votre fournisseur. Puis répétez-le, exactement comme le processus décrit dans notre playbook de réponse à incident.

Les étapes 4 et 5 sont celles où la plupart des équipes trichent : tout basculer en blocage dès le premier jour, casser le paiement pour un segment de vrais clients, puis couper tout le WAF dans la panique. Le mode comptage d'abord n'est pas de la prudence de façade. C'est la différence entre un contrôle auquel vous faites confiance et une case cochée qui vous fait peur.

L'exploiter au quotidien : la partie que personne ne budgète

Un WAF n'est pas un achat, c'est une pratique. Les règles se périment à mesure que votre application évolue. L'outillage des bots change tous les mois, et les réseaux de proxys résidentiels affaiblissent la réputation IP d'année en année. Budgétez une petite tranche récurrente de temps d'ingénierie : revue d'un échantillon de blocages chaque semaine au début, chaque mois une fois le système stabilisé. Suivez deux chiffres dans la durée : les signalements de faux positifs remontés par le support, et les requêtes par seconde à l'origine pendant les fenêtres d'attaque comparées aux périodes calmes. Le premier vous dit si vous êtes trop agressif, le second si l'edge absorbe réellement quelque chose. Si les deux courbes sont plates et ennuyeuses, le système fonctionne. L'ennui, c'est l'objectif.

Comment Innovation T peut vous aider

Innovation T conçoit et exploite la sécurité edge de systèmes en production, en Europe comme en Afrique francophone : architecture et réglage de WAF sur Cloudflare et AWS, revues de résilience DDoS, verrouillage d'origine, conception de rate limiting, et l'observabilité qui prouve que tout cela fonctionne. Nous construisons les règles, les pipelines et les runbooks, puis nous formons vos équipes à se les approprier.

Si votre application n'est qu'à un moment viral ou un botnet rancunier de la panne, réglons cela avant que cela n'arrive. Découvrez nos services ou échangez avec notre équipe pour une revue ciblée de votre sécurité edge.