Qu'est-ce qu'une attaque DDoS de couche applicative ?

Qu'est-ce qu'une attaque DDoS de couche applicative ?

Une attaque DDoS de couche applicative — aussi appelée attaque Layer-7 (L7) — submerge une application web en l'inondant de requêtes qui ressemblent à du trafic utilisateur légitime. Contrairement aux attaques volumétriques qui saturent la bande passante réseau (Layer 3/4), les attaques L7 ciblent la logique applicative elle-même : demander des endpoints coûteux, marteler des formulaires de recherche, abuser des pages de connexion, ou simplement demander la homepage plus vite que le serveur ne peut la rendre. La bande passante consommée est petite ; la charge CPU et base de données est énorme.

Les attaques L7 sont dangereuses précisément parce qu'elles paraissent réelles. Une avalanche de requêtes HTTP GET vers /search?q=anything peut faire tomber un site sans dépasser la bande passante qu'un seul utilisateur haut débit consommerait. Les protections DDoS génériques qui filtrent par volume de trafic laissent passer ces attaques.

Comment fonctionnent les attaques DDoS de couche applicative

L'attaquant contrôle un botnet — typiquement des milliers de navigateurs compromis, d'appareils IoT ou d'instances cloud louées. Chaque bot envoie une requête petite mais coûteuse en ressources à la cible. Patterns d'attaque courants :

• HTTP flood : Volume massif de requêtes GET ou POST vers des endpoints coûteux (recherche, homepage dynamique, login). Chaque requête peut prendre 100-500 ms de temps serveur ; des milliers par seconde saturent le pool de workers.
• Slowloris : Ouvrir de nombreuses connexions TCP au serveur, envoyer les headers lentement (un octet toutes les quelques secondes), ne jamais finir la requête. Les connexions restent ouvertes consommant des slots serveur ; les utilisateurs légitimes ne peuvent pas se connecter parce que le pool est épuisé.
• RUDY (R-U-Dead-Yet) : Comme Slowloris mais pour les requêtes POST — envoyer les headers POST, puis distiller le body en minuscules chunks pendant des heures.
• Cache-busting : Ajouter des paramètres de query uniques (?id=12345) pour que chaque requête manque le cache CDN et frappe l'origine. Efficace contre les sites qui comptent sur l'absorption CDN.
• Abus d'endpoint API : Appeler de manière répétée des endpoints coûteux (recherche, recommandations, agrégations complexes) qu'aucun utilisateur normal n'appellerait des milliers de fois par seconde.

Pourquoi les attaques L7 sont plus dures à défendre que L3/L4

Les attaques volumétriques (Layer 3/4) s'annoncent avec des volumes de trafic absurdes — votre CDN voit 100 Gbps entrants et drop le déchet évident avant qu'il n'atteigne l'origine. Les attaques L7 envoient des requêtes HTTP petites, individuellement-d'apparence-légitime à volume agrégé modéré. Le défi défensif :

• Chaque requête paraît valide. Filtrer par volume seul n'attrape rien — la bande passante a l'air normale.
• Spoofing de user-agent. Les bots modernes envoient des user-agents de navigateur réalistes. Bloquer par UA n'attrape que les bots évidents.
• Origine distribuée. Les botnets s'étendent sur des milliers d'IPs résidentielles. Bloquer par IP c'est whack-a-mole.
• La détection comportementale requiert du contexte. La vraie protection a besoin de comprendre ce qui est normal pour votre app — taux de requête par session, patterns de navigation, distributions de temps-sur-page. C'est cher à construire correctement.

Comment se défendre contre le DDoS de couche applicative

Web Application Firewall (WAF) avec rate limiting

Une WAF (Cloudflare, AWS WAF, Akamai) se place devant l'origine et applique des règles : rate-limit par IP, par session, par endpoint. Les WAFs modernes incluent des managed rule sets qui reconnaissent les patterns d'attaque courants (Slowloris, RUDY, fingerprints de bots courants) automatiquement.

CAPTCHAs et pages de challenge

Quand la WAF détecte des patterns suspects (ex. 50 req/sec depuis une seule IP), servir un CAPTCHA ou un challenge JavaScript. Les bots échouent au challenge ; les vrais utilisateurs le complètent. Le mode "Under Attack" de Cloudflare fait ça automatiquement.

Rate limit au niveau applicatif

Même avec une WAF, la défense en profondeur compte. Le rate-limiting au niveau applicatif par utilisateur/session/IP attrape les attaques qui passent le périmètre. Express/Nginx/Envoy le supportent tous.

Cacher agressivement

Les attaques de cache-busting échouent contre des endpoints bien cachés. Configurez Cache-Control sur tous les endpoints GET. Variez sur des headers minimaux (n'incluez pas les cookies dans la clé de cache pour les pages non-personnalisées).

Monitorer et alerter

La détection précède la mitigation. Monitorez le taux de requêtes, le taux d'erreur, la latence p95. Quand la WAF s'active, vous devriez déjà le savoir — les alertes proactives à des seuils plus bas attrapent l'attaque avant qu'elle ne cascade.

FAQ : DDoS de couche applicative

Quelle taille doit avoir une attaque L7 pour faire tomber un site ?

Plus petite que les gens ne pensent. Un botnet de 5 000-10 000 nœuds frappant des endpoints coûteux à des taux modérés peut submerger le pool de workers d'une app SaaS typique de taille moyenne. Bande passante : triviale. CPU/BDD : catastrophique.

Le palier gratuit de Cloudflare protège-t-il contre les attaques L7 ?

Partiellement. Cloudflare gratuit fournit du rate limiting basique et le mode "Under Attack", ce qui aide pour les attaques non sophistiquées. Les attaques L7 persistantes ou à grande échelle ont besoin du tier Pro/Business avec des règles WAF managées et des rate limits custom.

Quelle est la différence entre un L7 DDoS et un HTTP flood ?

HTTP flood est un type de L7 DDoS — le plus courant. D'autres catégories d'attaque L7 (Slowloris, RUDY, cache-busting, abus d'API) sont toutes au Layer 7 mais utilisent des techniques différentes.

Les tests de charge peuvent-ils simuler un L7 DDoS ?

Oui — c'est exactement ce que font les tests de stress et de soak. LoadFocus exécute des scripts JMeter ou k6 à haute concurrence depuis l'infrastructure cloud pour valider que votre app reste réactive sous charge. La différence avec une vraie attaque : les tests de charge respectent les rate limits et s'arrêtent au signal ; les attaquants non.

Devrais-je rate-limiter par IP, session ou les deux ?

Les deux. Le rate-limiting par IP attrape les bots évidents depuis des IPs uniques. Le rate-limiting par session/utilisateur attrape les attaques distribuées venant de milliers d'IPs mais coordonnées contre la même cible. Empilez-les.

Comment savoir si je suis attaqué vs si j'ai du trafic organique ?

Comparez la forme actuelle du trafic à votre baseline normale : distribution des requêtes entre endpoints, taux d'erreur, distribution géographique, diversité des user-agents. Une attaque montre typiquement de l'uniformité (mêmes endpoints, même user-agent, mêmes régions) tandis que le trafic organique est désordonné.

Comment LoadFocus aide à se préparer aux L7 DDoS

LoadFocus exécute des tests de charge JMeter et k6 scriptables contre vos endpoints à des échelles qui imitent les patterns d'attaque L7 — haute concurrence, ciblage d'endpoints coûteux, variations de cache-busting. Utilisez-le pour valider que vos rate limits fonctionnent avant qu'un attaquant ne les teste. Exécutez un test de pattern d'attaque depuis loadfocus.com/fr-fr/free-load-test ou combinez avec le monitoring d'API sur loadfocus.com/fr-fr/api-monitoring pour validation continue.