Qu'est-ce qu'une attaque HTTP Flood DDoS ?

Qu'est-ce qu'une attaque HTTP flood DDoS ?

Un HTTP flood est une attaque DDoS Layer-7 (couche applicative) où l'attaquant envoie des volumes massifs de requêtes HTTP GET ou POST à un serveur web cible. Chaque requête individuelle paraît légitime — HTTP bien formé, header user-agent réaliste, URL plausible — ce qui rend les HTTP floods difficiles à filtrer sans bloquer de vrais utilisateurs au passage. Les HTTP floods sont le pattern d'attaque DDoS L7 le plus courant : simples à exécuter, difficiles à défendre et disproportionnellement destructifs par rapport à la bande passante consommée.

Contrairement aux attaques volumétriques (Layer 3/4) qui saturent la bande passante réseau avec des floods de paquets bruts, les HTTP floods épuisent les ressources côté serveur : pools de workers de serveur web, connexions à la base de données, mémoire applicative et quotas d'API downstream. Un botnet de 5 000-10 000 nœuds martelant un endpoint coûteux à 5 requêtes/seconde par nœud — 25 000-50 000 RPS agrégées — peut faire tomber une application SaaS typique de taille moyenne sans dépasser la bande passante qu'un seul utilisateur résidentiel haut débit consommerait.

Comment fonctionnent les attaques HTTP flood

L'attaquant contrôle un botnet — un réseau d'appareils compromis : navigateurs piratés, appareils IoT (caméras, routeurs, appareils smart) ou instances cloud louées achetées sur des forums darkweb pour 5-50 $/heure pour de courtes attaques. Chaque bot dans le réseau envoie des requêtes HTTP à la cible avec ces caractéristiques :

• HTTP bien formé. Vraies requêtes HTTP/1.1 ou HTTP/2 avec des headers valides — Host, User-Agent (souvent spoofed pour ressembler à Chrome/Safari/Firefox), Accept, etc. Tout ce qui échoue au parsing HTTP de base est de toute façon droppé à la WAF.
• IPs sources distribuées. Les requêtes viennent de milliers d'IPs géographiquement dispersées — typiquement espace IP résidentiel loué d'appareils compromis, pools CGNAT FAI ou plages d'IPs transitoires de fournisseurs cloud.
• Sélection d'endpoint ciblée. Les attaquants malins ciblent les endpoints les plus coûteux : /search?q=..., /api/recommendations, la homepage dynamique sans caching, formulaires de login qui frappent la base de données d'auth. Chaque requête déclenche du travail CPU et base de données significatif.
• Variation cache-busting. Ajouter des paramètres de query uniques ou randomiser des fragments pour forcer chaque requête à travers le CDN vers l'origine : /search?q=test&_cb=12345, /search?q=test&_cb=12346, etc. Le caching CDN devient inutile.

HTTP flood vs autres patterns d'attaque L7

HTTP flood est l'attaque L7 la plus courante mais plusieurs variantes et patterns adjacents existent :

• HTTP flood (cette entrée) : Volume élevé de requêtes HTTP entièrement formées. Peut être GET-flood (endpoints read-heavy) ou POST-flood (endpoints write-heavy — souvent plus dommageables car les écritures frappent la base de données).
• Slowloris : Ouvre de nombreuses connexions TCP, envoie des headers HTTP partiels lentement, ne les termine jamais. Les connexions restent ouvertes consommant des slots serveur ; les utilisateurs légitimes ne peuvent pas se connecter parce que le pool de connexions est épuisé.
• RUDY (R-U-Dead-Yet) : Attaque slow POST — envoie des headers POST valides, puis distille le body en minuscules chunks pendant des heures. Le serveur web maintient la connexion vivante en attendant que le body se complète.
• GET récursif : Martèle les endpoints récursifs coûteux (recherche-avec-filtres, agrégations complexes) qui touchent beaucoup de services backing par requête.
• Form-spam flood : POST-floods sur des formulaires (login, signup, contact) qui déclenchent des effets secondaires downstream : emails envoyés, nouveaux records utilisateur, entrées de log.

Pourquoi les HTTP floods sont dangereux

• Difficile de distinguer des vrais utilisateurs. Un pic de GETs vers la homepage depuis des milliers d'IPs distinctes ressemble à un hit viral OU à un HTTP flood. Les défenseurs doivent choisir : bloquer agressivement et perdre des vrais utilisateurs, ou être permissifs et rester vulnérables.
• Amplification de ressources. Une requête HTTP de 1 Ko peut déclencher une query base de données de 100 ms plus un appel de recommandation de 200 ms plus un hit API downstream de 50 ms. Chaque octet d'input d'attaque devient 100+ octets de travail côté serveur.
• Amplification de coûts. Si vous autoscalez sur le trafic, un HTTP flood scale votre facture infrastructure vers le haut. L'attaquant paie pour un botnet ; vous payez AWS pour les workers servant l'attaquant.
• Échecs en cascade. Quand le pool de workers est saturé, les vrais utilisateurs commencent à timeout. Leurs navigateurs réessayent, augmentant la charge encore plus. L'application peut tomber avant que l'attaque n'atteigne la "saturation" dans aucun sens traditionnel.

Comment se défendre contre les HTTP floods

WAF avec rate limiting

Une WAF moderne (Cloudflare, AWS WAF, Akamai, Fastly) se place devant l'origine et applique des rate limits par IP, par session, par endpoint. La plupart des managed rule sets WAF reconnaissent les fingerprints de bots courants et les patterns de HTTP flood automatiquement. Tunez le rate limit à votre pic de trafic normal plus 50% de marge — tout ce qui est au-dessus déclenche la WAF.

Challenges JavaScript et CAPTCHAs

Quand la WAF détecte un pattern flood, servez un challenge JavaScript ou CAPTCHA. La plupart des botnets n'exécutent pas JavaScript ni ne résolvent CAPTCHAs à l'échelle ; les vrais navigateurs si. Le mode "Under Attack" de Cloudflare automatise ça. Les challenges modernes sont invisibles pour la plupart des utilisateurs légitimes.

Caching agressif

Les attaques de cache-busting échouent contre les endpoints bien cachés. Configurez Cache-Control: max-age sur tous les endpoints GET. Utilisez un CDN avec de hauts ratios de cache hit. Pour les endpoints dynamiques, considérez stale-while-revalidate pour servir du contenu caché pendant que l'origine récupère.

Rate limiting au niveau applicatif

Défense en profondeur. Même avec une WAF, votre application devrait rate-limiter au niveau session/utilisateur. Une WAF attrape les floods basés sur IP ; les rate limits applicatifs attrapent les attaquants qui rotent à travers des IPs résidentielles mais coordonnent contre les mêmes comptes.

Préparez-vous au failover

Identifiez vos endpoints les plus coûteux et ayez un plan circuit-breaker. Si /api/recommendations est le goulot d'étranglement pendant les attaques, configurez-le pour retourner un fallback caché ou une réponse d'erreur simple quand la charge dépasse X requêtes/seconde. Mieux dégrader une fonctionnalité qu'effondrer tout le site.

Monitorez et alertez proactivement

Vous devriez savoir d'un HTTP flood avant vos clients. Alertez sur : taux de requêtes au-dessus de 2x la baseline rolling, taux d'erreur au-dessus de 1%, latence p95 au-dessus du SLO. La mitigation automatisée (auto-activation WAF) ferme le gap de "détecté" à "mitigé" mais le monitoring proactif attrape les attaques que la WAF n'attrape pas.

FAQ : Attaques HTTP Flood DDoS

Quelle taille doit avoir un HTTP flood pour faire tomber un site ?

Plus petite que les gens ne pensent. 25 000-50 000 RPS ciblant des endpoints coûteux peuvent submerger le pool de workers d'une application SaaS typique de taille moyenne. Les attaquants n'ont pas besoin de millions de requêtes par seconde — juste assez pour saturer vos endpoints les plus coûteux plus vite que l'autoscale ne peut réagir.

Le plan gratuit de Cloudflare arrête-t-il les HTTP floods ?

Partiellement. Le plan gratuit fournit la protection DDoS basique (surtout Layer 3/4) et le mode "Under Attack" pour les attaques L7. Les HTTP floods persistants ou sophistiqués ont besoin du plan Pro/Business avec des règles WAF managées, des contrôles de rate-limiting et de la gestion de bots.

Comment distinguer un HTTP flood d'un pic de trafic viral ?

Regardez la forme du trafic : les pics viraux se concentrent sur une ou quelques URLs (la page qui est devenue virale) avec des user-agents, géographie et referrers divers. Les floods sont uniformes : mêmes URLs frappées par mêmes user-agents depuis mêmes régions, pas de referrers organiques. Le taux de conversion aide aussi — le trafic viral convertit ; le trafic flood non.

Puis-je lancer un test de charge qui imite un HTTP flood ?

Oui — c'est exactement ce que fait le stress testing. Utilisez LoadFocus pour exécuter des scripts JMeter ou k6 à haute concurrence depuis des régions cloud, frappant vos endpoints coûteux avec des formes de requête réalistes. Valide que vos rate limits, CDN et autoscale fonctionnent AVANT qu'un attaquant ne les teste. La différence : les tests de charge respectent les rate limits et s'arrêtent au signal ; les attaquants non.

Devrais-je rate-limiter par IP ou par session ?

Les deux. Le rate-limiting par IP attrape les attaques depuis des sources uniques. Le rate-limiting par session/utilisateur attrape les attaques distribuées venant de milliers d'IPs mais coordonnées contre vos endpoints. Empilez-les — aucun seul ne suffit.

Quel est le coût de ne pas être préparé à un HTTP flood ?

Trois buckets : direct (coût de downtime — transactions perdues, pénalités SLA), indirect (coût d'autoscale — votre facture infrastructure multipliée pendant que le trafic d'attaque est servi), réputationnel (churn client après pannes publiques, chutes de classement si Googlebot ne peut pas crawler pendant les attaques). Pour un site e-commerce typique, une panne de 4 heures pendant le pic de trafic coûte cinq chiffres minimum.

Comment LoadFocus vous aide à vous préparer aux HTTP floods

LoadFocus exécute des tests de charge JMeter et k6 scriptables à des échelles qui imitent les patterns d'attaque HTTP flood : RPS élevées, ciblage d'endpoints coûteux, variations de cache-busting. Lancez un stress test depuis loadfocus.com/fr-fr/free-load-test contre votre environnement staging pour valider que vos rate limits, caching CDN et autoscale fonctionnent avant qu'un attaquant ne les stress-teste pour vous. Couplez avec le monitoring d'API depuis 25+ régions pour attraper les vraies attaques tôt.