CDN, WAF, anti-DDoS : lire les services de bordure

40 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 9 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Les services de bordure se placent entre Internet et le point d'entrée d'une application, au plus près des visiteurs : un CDN sert le contenu depuis un point proche, un pare-feu applicatif filtre les requêtes malveillantes, une protection anti-DDoS absorbe les volumes destinés à saturer le réseau. Chacun traite un problème précis et aucun ne remplace l'autre. Cette leçon apprend à les distinguer, à lire leur ordre de traversée, à qualifier ce qu'ils gardent et ce que coûte leur panne, et à repérer le contournement qui annule toute la bordure.

Ce que vous allez apprendre

Dire ce que traitent un CDN, un pare-feu applicatif et une protection anti-DDoS
Expliquer l'ordre de ces couches devant une application
Qualifier l'état d'un CDN et l'impact de sa panne
Repérer le contournement d'une bordure par l'adresse d'origine

Qu'est-ce qu'un CDN ?

Un CDN (Content Delivery Network, réseau de diffusion de contenu) est un ensemble de serveurs répartis dans le monde qui gardent une copie des contenus d'un site et les servent depuis le point le plus proche du visiteur. Le serveur d'origine, celui de l'application, n'est sollicité que lorsque le CDN n'a pas le contenu en cache ou que sa copie a expiré. Images, scripts, feuilles de style et pages qui changent peu en sont les clients naturels.

Le gain est double : le visiteur attend moins, puisque le contenu vient de près, et l'origine reçoit une fraction du trafic. Le prix tient dans la fraîcheur : une copie en cache peut être périmée tant qu'elle n'a pas expiré ou n'a pas été invalidée. Un CDN ne protège pas, à lui seul, contre une requête applicative malveillante : il la transmet à l'origine comme une autre si elle n'est pas en cache.

Qu'est-ce qu'un pare-feu applicatif ?

Un pare-feu applicatif (WAF, Web Application Firewall) inspecte le contenu des requêtes HTTP et bloque celles qui correspondent à des motifs d'attaque connus : injection SQL, script intersite, scans automatisés. Il travaille à la couche 7, là où un pare-feu réseau ne voit que des adresses et des ports. Ses règles viennent souvent de jeux génériques dérivés des travaux de l'OWASP, puis d'exceptions propres à l'application.

Un WAF est un filtre, jamais un correctif : il réduit le bruit des scanners et gagne du temps face à une faille connue, il ne rend pas sûre une application qui ne l'est pas. Ses règles génériques bloquent aussi du trafic légitime, comme un formulaire de texte libre, d'où un passage par un mode observation avant tout blocage.

Qu'est-ce qu'une protection anti-DDoS ?

Une protection anti-DDoS (déni de service distribué) absorbe les volumes de trafic destinés à saturer la liaison réseau ou la pile réseau d'un service. Elle agit sur les couches réseau et transport : inondations de paquets, amplification par des serveurs DNS ou NTP mal configurés. Les grands fournisseurs cloud l'incluent par défaut pour ces attaques volumétriques.

Ce qu'elle ne voit pas, ce sont les attaques applicatives : des requêtes HTTP bien formées, en volume modeste, mais coûteuses pour la base de données. Elles relèvent du WAF, de la limitation de débit et d'offres anti-DDoS avancées. Dans une infrastructure élastique, une telle attaque peut ne rien casser et pourtant coûter cher : l'application grossit pour lui répondre.

Dans quel ordre placer ces couches ?

Chaque couche doit recevoir un trafic déjà nettoyé par la précédente : protection volumétrique d'abord, puis CDN, puis pare-feu applicatif, puis le point d'entrée de l'application. Placer le WAF derrière le CDN lui évite d'inspecter les requêtes servies depuis le cache, qui n'atteignent jamais l'origine. Le schéma suit une requête qui traverse toute la bordure.

Les trois services de bordure, mis en avant, dans l'ordre où le trafic les traverse. Source · SVG

Le libellé de la flèche entre le CDN et le WAF porte l'essentiel : seule la requête non mise en cache continue. Sur un site où la majorité du trafic est statique, l'origine et le WAF ne voient qu'une petite partie des requêtes. Le guide Exposer une application : CDN, WAF, passerelle d'API et liens privés détaille cet ordre et les offres des fournisseurs.

Quel état portent les services de bordure ?

Les services de bordure ne portent aucune donnée métier, mais ils portent une configuration critique et, pour le CDN, des copies jetables. Le contenu en cache d'un CDN est une donnée dérivée : sa perte coûte du trafic vers l'origine, pas d'information. Les règles du WAF, la configuration des domaines et les certificats de bordure sont en revanche un état à garder dans un dépôt et à savoir reconstruire.

Question de la grille	CDN	Pare-feu applicatif	Anti-DDoS
Ce qu'il traite	le contenu servi, au plus près	le contenu des requêtes HTTP	le volume réseau
État porté	copies en cache, configuration	règles et exceptions	configuration du fournisseur
À sauvegarder	la configuration, pas le cache	les règles, dans un dépôt	en général rien
S'il tombe	l'origine reçoit tout le trafic, ou le site est injoignable	trafic non filtré ou bloqué selon le réglage	l'origine subit l'attaque
Signal à surveiller	taux de réponses servies depuis le cache	requêtes bloquées, faux positifs	volume entrant anormal

La panne d'un CDN se lit sur le DNS : si le nom du site pointe vers le CDN, sa panne rend le site injoignable, même avec une origine en parfait état. C'est une dépendance à un fournisseur externe, dont le rayon d'impact couvre tous les visiteurs.

Ce que la bordure change dans la boutique

Dans la boutique, la bordure se place devant le reverse proxy et le répartiteur : elle sert les images du catalogue depuis le cache, filtre les requêtes suspectes et encaisse les attaques volumétriques. Le point d'entrée ne voit plus qu'une fraction du trafic, surtout les commandes et les pages personnalisées. La version 1 du fil rouge la dessine comme une seule boîte, pour ne pas alourdir le schéma.

Version 1 du fil rouge : la bordure est la première brique traversée par l'utilisateur. Source · SVG

Ce changement en entraîne un autre, qu'on oublie souvent : l'adresse source que voit la boutique devient celle du CDN, pas celle du visiteur. L'adresse réelle voyage dans un en-tête HTTP, qu'il faut lire en ne faisant confiance qu'à la couche précédente, faute de quoi n'importe qui peut usurper l'adresse de son choix et contourner les limitations par adresse.

Une bordure : ce qu'elle apporte, ce qu'elle coûte

Une bordure soulage et protège l'origine, au prix d'une dépendance externe et de nouvelles façons d'avoir tort. Le tableau pose ce compromis pour la boutique, quand on ajoute un CDN et un WAF devant son point d'entrée.

Ce qu'on gagne	Ce qu'on paie
images et pages servies vite, partout	du contenu parfois périmé, à invalider
une origine qui reçoit une fraction du trafic	une dépendance à un fournisseur dont la panne coupe le site
un filtrage des attaques connues et des scanners	des faux positifs qui bloquent de vrais clients
les attaques volumétriques absorbées en amont	l'adresse réelle du visiteur à lire dans un en-tête

Le contournement qui annule la bordure

Une bordure ne protège rien si l'origine accepte aussi le trafic qui ne passe pas par elle. Un attaquant qui découvre l'adresse publique de l'origine, par exemple dans l'historique public des certificats ou dans d'anciens enregistrements DNS, l'attaque directement, sans traverser ni le CDN ni le WAF. Toute la pile devient décorative.

La parade se lit sur le schéma : l'origine ne doit accepter que le trafic venu de la couche précédente, par une règle réseau limitée aux adresses du fournisseur de bordure, un lien privé ou une authentification entre la bordure et l'origine. Devant tout schéma de bordure, la question à poser est donc : le point d'entrée est-il joignable sans passer par la bordure ?

Qui prend le relais pour installer et exploiter ces briques ?

Cette leçon décrit le rôle des services de bordure ; leur mise en place et leur réglage relèvent des guides spécialisés. Le guide Exposer une application traite les offres managées, l'activation d'un WAF en mode comptage et l'ordre des couches ; le guide BunkerWeb déploie un pare-feu applicatif auto-hébergé ; le guide CrowdSec ajoute une détection collaborative des attaques. Ce sont eux qu'il faut suivre pour mettre ces protections en service.

Pièges de lecture courants

Ces confusions reviennent devant un schéma de bordure, et elles viennent surtout d'une protection qu'on croit plus large qu'elle n'est, ou d'une origine restée joignable :

Croire qu'un CDN protège l'application : il transmet à l'origine toute requête qu'il n'a pas en cache.
Prendre la protection anti-DDoS incluse pour une protection applicative : elle ne voit pas les requêtes HTTP bien formées.
Voir le WAF comme un correctif : il filtre, la faille reste.
Laisser l'origine joignable directement : la bordure est contournée.
Oublier la dépendance au fournisseur : sa panne coupe le site, origine saine ou non.

À retenir

Le CDN sert le contenu au plus près, le WAF filtre le contenu des requêtes, l'anti-DDoS absorbe le volume réseau.
L'ordre est anti-DDoS, CDN, WAF, puis le point d'entrée : chaque couche reçoit un trafic déjà nettoyé.
Le cache d'un CDN est une donnée dérivée ; ses règles et certificats sont un état à garder.
Une bordure ajoute une dépendance externe et masque l'adresse réelle des visiteurs.
L'origine ne doit accepter que le trafic de la bordure, sinon tout est contournable.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin