Pourquoi filtrer à l'edge change la donne
Lorsque votre serveur applicatif effectue lui-même ses contrôles de sécurité, chaque requête malveillante l'atteint quand même, consomme du CPU, ouvre une connexion base de données, et entre en concurrence avec les vrais utilisateurs pour les ressources. cdn.com.tr déplace cette inspection à l'edge, si bien que les tentatives d'injection, les sondes de scanners et le trafic indésirable sont rejetés loin de votre origine et ne touchent jamais votre code ni votre base de données. C'est la différence entre un serveur qui plie sous une attaque et un serveur qui la remarque à peine, car la charge abusive est absorbée par un réseau distribué conçu pour l'encaisser.
Le jeu de règles WAF géré
Le pare-feu applicatif web inspecte la méthode de requête, le chemin, les en-têtes et le corps par rapport à des règles qui reconnaissent les classes d'attaque bien connues : injection SQL, cross-site scripting, inclusion de fichiers distants, path traversal et injection de commandes, entre autres. Ces règles sont maintenues de manière centralisée afin que vous bénéficiiez des mises à jour sans modifier votre propre configuration, ce qui compte le plus pour des plateformes comme WordPress et le PHP legacy, où l'application elle-même peut être lente à corriger. Vous pouvez activer la protection par domaine et superposer vos propres règles d'autorisation et de refus pour des chemins spécifiques à l'application.
Absorber les inondations DDoS
Une attaque par déni de service distribué tente d'épuiser votre capacité en envoyant bien plus de trafic qu'une seule origine ne peut en absorber. Comme cdn.com.tr place votre domaine derrière un edge distribué, les inondations volumétriques sont réparties sur le réseau et filtrées avant de se concentrer sur votre serveur, et les réponses mises en cache continuent d'être servies depuis l'edge même pendant qu'une attaque est en cours. Le résultat concret est que votre origine reste accessible pour les visiteurs légitimes précisément dans les moments où un site non protégé s'effondrerait.
Rate limiting et mitigation de bots
Toute menace n'est pas une signature ; certaines sont simplement trop de requêtes venant d'un même client. Le rate limiting vous permet de plafonner la fréquence à laquelle une IP peut solliciter des points d'entrée sensibles tels que les formulaires de connexion, les réinitialisations de mot de passe, ou des routes d'API coûteuses, ce qui stoppe le credential stuffing par brute-force et le scraping agressif sans bloquer les utilisateurs normaux. Combiné à des règles d'accès par pays et par IP, cela vous donne un moyen d'arrêter une automatisation abusive qu'un pare-feu basé uniquement sur des signatures manquerait, le tout configurable par domaine depuis le panel.
Masquer l'origine supprime le contournement
Un pare-feu à l'edge ne fonctionne que si les attaquants ne peuvent pas le contourner, et l'erreur classique est de laisser le serveur d'origine accessible sur sa véritable IP. cdn.com.tr vous encourage à verrouiller l'origine pour qu'elle n'accepte des connexions que depuis l'edge et à garder son adresse hors du DNS public, ce qui signifie que le seul chemin vers votre application passe par la couche de sécurité. Cette protection de l'origine transforme le WAF d'un simple ralentisseur optionnel en un point de passage obligatoire, et réduit également la surface d'attaque exposée aux scanners d'internet.
Une seule politique de sécurité pour toutes vos applications
Que vous publiiez un site WordPress, un portail PHP legacy, ou une API basée sur des containers, le même modèle de sécurité edge s'applique dès que le domaine est routé via cdn.com.tr. Cela signifie que vous ne maintenez pas une pile de pare-feu distincte par application ; vous attachez le domaine, activez le WAF, définissez des limites de débit, et la politique le protège uniformément. Pour les équipes qui gèrent plusieurs sites ou services, cette cohérence est ce qui rend la sécurité gérable au lieu d'être une course au coup par coup pour chaque projet.
Comment le configurer, étape par étape
Routez le domaine à travers l'edge
Ajoutez le nom d'hôte à votre compte CDN et pointez son DNS vers l'edge de cdn.com.tr. À partir de ce moment, chaque requête pour le domaine entre d'abord dans un edge node, ce qui est le prérequis pour qu'une politique de sécurité s'applique, car un pare-feu n'aide que si tout le trafic y passe réellement.
Activez le WAF pour le domaine
Activez le pare-feu applicatif web dans le panel pour ce domaine. Le jeu de règles géré commence immédiatement à inspecter les requêtes à la recherche de signatures d'attaque courantes telles que l'injection SQL, le cross-site scripting et le path traversal, sans aucune modification de votre application.
Masquez et verrouillez votre origine
Une fois le trafic passant par l'edge, restreignez votre origine pour qu'elle n'accepte que les connexions provenant de cdn.com.tr, et cessez de publier sa véritable IP dans le DNS public. Cela ferme la faille par laquelle un attaquant frapperait directement l'origine en contournant totalement le WAF.
Ajoutez des limites de débit et des règles d'accès
Configurez le rate limiting sur les points d'entrée sensibles tels que /wp-login.php, /xmlrpc.php, ou la route d'authentification de votre API, et ajoutez des règles d'autorisation/refus par pays ou par IP si nécessaire. Cela stoppe les abus de type brute-force et scraping avant qu'ils ne consomment les ressources applicatives.
Confirmez le TLS et forcez le HTTPS
Avec Auto SSL en place, activez la redirection HTTPS afin que chaque requête soit mise à niveau vers TLS à l'edge. Cela garantit que le trafic inspecté puis transmis à votre origine est chiffré de bout en bout pour les visiteurs.
Observez, puis ajustez
Passez en revue ce que le WAF bloque, confirmez que le trafic légitime n'est pas capturé, et ajustez les règles ou les exceptions pour les rares faux positifs. La sécurité est une politique que l'on affine dans le temps, pas un interrupteur qu'on bascule une fois, et le panel vous donne la visibilité nécessaire pour le faire en toute sécurité.
Exemples de scénarios
Un site WordPress active le WAF et limite le débit sur /wp-login.php et /xmlrpc.php, coupant les bots de brute-force à l'edge afin que le processus PHP et la base de données ne soient jamais touchés par le trafic d'attaque.
Une API JSON basée sur des containers est publiée avec le WAF activé et des limites de débit par route, si bien que le scraping et les tentatives d'injection sont filtrés avant d'atteindre le service, tandis que l'origine est verrouillée pour n'accepter que les connexions de l'edge.
En amont d'un lancement très médiatisé, un site s'appuie sur l'absorption DDoS à l'edge et la diffusion depuis le cache, afin qu'une hausse soudaine, qu'il s'agisse de vrais visiteurs ou d'une attaque, soit répartie sur le réseau au lieu de faire s'effondrer l'origine.
Questions fréquentes
Dois-je modifier le code de mon application pour utiliser le WAF ?
Non. Le pare-feu opère à l'edge sur le chemin de la requête, si bien qu'il inspecte et bloque le trafic avant qu'il n'atteigne votre application. Vous l'activez par domaine dans le panel ; votre code, votre framework et la configuration de votre serveur restent exactement tels quels.
Quels types d'attaques le WAF arrête-t-il réellement ?
Le jeu de règles géré cible les classes d'attaque web courantes, notamment l'injection SQL, le cross-site scripting, le path traversal, l'inclusion de fichiers distants et l'injection de commandes, ainsi que le volume abusif via le rate limiting. Il est conçu pour intercepter les tentatives de sondage et d'exploitation automatisées qui constituent l'essentiel du trafic web hostile.
Les attaquants peuvent-ils contourner le WAF en atteignant directement mon origine ?
Seulement si vous laissez l'origine exposée. La configuration recommandée verrouille votre origine pour n'accepter que les connexions provenant de l'edge cdn.com.tr et garde sa véritable IP hors du DNS public, si bien que le seul chemin vers votre application passe par la couche de sécurité et que les attaques directes sur l'origine sont coupées.
Le WAF va-t-il bloquer des visiteurs légitimes par erreur ?
Les faux positifs sont possibles avec n'importe quel pare-feu, c'est pourquoi le panel vous permet de voir ce qui est bloqué et d'ajouter des exceptions pour des chemins ou des clients spécifiques. L'approche pratique consiste à activer la protection, observer les résultats, et ajuster les règles pour que le trafic authentique circule tandis que les attaques restent bloquées.
En quoi la protection DDoS diffère-t-elle du WAF ?
Ils résolvent des problèmes différents. Le WAF inspecte le contenu de chaque requête individuelle à la recherche de schémas malveillants, tandis que la protection DDoS traite le pur volume en répartissant et en absorbant les inondations sur l'edge distribué. Une attaque sérieuse implique souvent les deux, si bien que les deux couches travaillent ensemble devant votre origine.
Activer la sécurité ralentit-il mon site ?
L'edge se trouve déjà sur le chemin de la requête pour le cache, donc l'ajout de l'inspection WAF n'introduit pas de saut supplémentaire, et les réponses mises en cache continuent d'être servies rapidement. En pratique, la même couche qui vous protège vous accélère également, puisque le trafic bloqué et le trafic mis en cache ne pèsent jamais sur votre origine.