Comment fonctionne Shield et comment configurer les protections de votre site ?

Introduction

Shield est le panneau de contrôle WAF de Fasterize. Il permet de piloter depuis la console Fasterize plusieurs mécanismes de protection appliqués à votre trafic : contrôle des accès, règles de sécurité personnalisées, limitation du trafic, protections WAF gérées, gestion des bots et en-têtes de sécurité.

Shield ne repose pas sur un niveau global de sécurité du type « faible », « moyen » ou « élevé ». Chaque protection constitue une brique indépendante, que vous pouvez configurer selon les besoins de votre site.

Ces briques ne fonctionnent cependant pas de manière isolée. Elles s’exécutent dans un ordre précis, et certaines décisions prises en amont peuvent avoir un impact sur les protections suivantes.

Comprendre cet ordre est donc essentiel avant de commencer à configurer Shield.

Dans quel ordre les protections Shield s’appliquent-elles ?

Lorsqu’une requête arrive sur votre site, elle traverse les protections Shield dans un ordre défini.

L’ordre affiché dans la console est le suivant :

• HTTP DDoS (L7)
• Contrôle d’accès
• Règles de sécurité
• Limitation de débit
• Règles managées
• Bots

La protection anti-DDoS HTTP L7 intervient en premier et reste toujours active.

Les En-têtes de sécurité fonctionnent différemment des autres briques : ils ne constituent pas une étape supplémentaire de filtrage de la requête. Ils agissent sur la réponse HTTP retournée au navigateur.

L’ordre d’exécution est important, car une décision prise tôt dans la chaîne peut modifier le comportement des protections situées plus loin.

C’est notamment le cas de l’action skip disponible dans les Règles de sécurité : lorsqu’elle s’applique, les règles de sécurité restantes, la limitation de débit, les Règles managées et la protection contre les bots sont contournées pour cette requête.

⚠️ Une exception trop large ou mal positionnée peut empêcher certaines protections de s’appliquer. Vérifiez toujours l’ordre des briques et l’ordre de vos règles.

Après une modification, la configuration est validée puis propagée. L’interface peut déjà afficher l’état souhaité pendant cette phase : le changement devient réellement actif une fois le déploiement terminé.

Comment fonctionne l’ordre des Règles de sécurité ?

Au sein de la brique Règles de sécurité, les règles sont évaluées de haut en bas.

Le principe est celui de la première correspondance pour les actions qui interrompent l’évaluation : lorsqu’une requête correspond à une règle appliquant une action terminante, les règles suivantes ne sont plus évaluées dans ce contexte.

💡 Exception importante : log n’interrompt pas l’évaluation. La règle est comptabilisée et les règles suivantes continuent de s’appliquer. C’est ce qui permet d’observer un trafic sans modifier son traitement.

Cette particularité est particulièrement utile lors de la création d’une nouvelle règle : vous pouvez commencer par observer les requêtes correspondantes avec log, puis ajuster votre expression avant d’appliquer une action plus restrictive.

L’ordre des règles a donc un impact direct sur leur comportement.

Comment contrôler rapidement les accès avec le Contrôle d’accès ?

Le Contrôle d’accès constitue la première couche configurable de Shield après la protection HTTP DDoS (L7).

Il permet de créer des listes d’éléments autorisés ou bloqués selon trois critères disponibles dans la console :

• IP Client ;
• Pays ;
• User agent.

Pour chaque catégorie, vous pouvez définir les éléments auxquels vous souhaitez autoriser ou refuser l’accès.

Une fois vos modifications effectuées, utilisez le bouton de sauvegarde des réglages. Comme pour les autres configurations Shield, les changements deviennent effectifs après leur déploiement.

Comment créer une Règle de sécurité personnalisée ?

Les Règles de sécurité permettent d’intercepter précisément certaines requêtes et d’appliquer une action lorsqu’une expression correspond.

Une règle comprend notamment :

• un nom ;
• une expression définissant les requêtes concernées ;
• une action ;
• un état activé ou désactivé.

Dans l’éditeur présenté, plusieurs champs peuvent être utilisés pour construire une expression, notamment :

• ip.src
• ip.src.country
• ip.src.asnum
• http.request.uri.path
• http.user_agent
• http.request.method
• http.host
• http.referer

Vous pouvez ainsi cibler une requête à partir de plusieurs critères.

L’exemple visible dans la console combine notamment le chemin de la requête, la méthode HTTP, le Content-Type et le host afin de cibler précisément un formulaire.

Quelles actions peut-on appliquer à une Règle de sécurité ?

La console propose plusieurs actions :

• block : refuse la requête ; la console indique un retour HTTP 403 ;
• managed challenge : applique un contrôle adapté au visiteur ;
• JS challenge : applique un contrôle JavaScript ;
• challenge : affiche un challenge interactif ;
• log : observe et comptabilise la correspondance sans interrompre l’évaluation ;
• skip : permet de contourner les protections suivantes concernées.

💡 Pour une nouvelle règle, log permet d’abord de vérifier quelles requêtes correspondent à votre expression sans modifier leur traitement. Comme log n’est pas une action terminante, les règles suivantes continuent d’être évaluées.

À quoi servent les listes nommées dans les expressions ?

Certaines règles visibles dans la console utilisent des listes nommées directement dans leurs expressions.

Elles permettent de faire référence à un ensemble de valeurs dans une condition, plutôt que de répéter toutes ces valeurs directement dans l’expression.

Comment configurer la Limitation de débit ?

La Limitation de débit, ou rate limiting, intervient après les Règles de sécurité.

Elle permet de compter les requêtes sur une période définie et d’appliquer une action lorsque le seuil configuré est dépassé.

Dans la capture fournie, deux règles de limitation de débit sont configurées. La règle Checkout protection applique une action block au-delà de 30 requêtes sur 60 secondes, avec une atténuation de 600 secondes. La règle Login protection applique quant à elle une action challenge au-delà de 10 requêtes sur 60 secondes, avec une atténuation de 60 secondes.

Une requête peut ne pas atteindre cette étape si une Règle de sécurité a appliqué en amont un skip.

La console recommande par ailleurs de commencer une nouvelle règle de limitation de débit en mode de journalisation afin de calibrer le seuil avant de l’appliquer.

Quel statut HTTP est renvoyé par la Limitation de débit ?

Lorsqu’une règle de limitation de débit utilise l’action block, le statut renvoyé est HTTP 429.

Il faut distinguer ce comportement du block d’une Règle de sécurité, qui renvoie HTTP 403.

Si l’action choisie pour la limitation de débit est un challenge, le statut observé ne sera pas 429.

Comment fonctionnent les Règles managées ?

La brique Règles managées regroupe plusieurs protections maintenues pour vous.

Protection anti-DDoS HTTP (L7)

La protection anti-DDoS HTTP (L7) est appliquée automatiquement.

Elle est indiquée comme toujours active dans la console et ne peut pas être désactivée.

Browser Integrity Check

Le Browser Integrity Check vérifie le User-Agent à la recherche de motifs associés à l’outillage automatisé.

Dans la configuration présentée, cette protection est désactivée par défaut.

WAF managé

Le WAF managé apporte une protection contre différentes menaces mentionnées dans la console, notamment :

• les injections SQL ;
• les attaques XSS ;
• les exploits et CVE connus.

Les actions associées au WAF managé peuvent être gérées depuis cette rubrique.

Comment gérer les exceptions du WAF managé ?

Si certaines règles du WAF managé sont trop bruyantes pour votre site, la console permet d’ajouter des exceptions.

Une exception peut notamment servir à conserver une règle en surveillance ou à la désactiver pour le périmètre concerné.

💡 Utilisez les exceptions de manière ciblée afin d’éviter de réduire inutilement le périmètre couvert par le WAF managé.

Comment gérer les Bots & trafic automatisé ?

La rubrique Bots & trafic automatisé permet de configurer le traitement de plusieurs catégories de trafic automatisé.

Assurance automatisée

Cette catégorie correspond au trafic identifié comme assurément automatisé, par exemple des scripts ou des outils.

La valeur par défaut indiquée est :

managed challenge

Bots vérifiés

Cette catégorie concerne les bots légitimes vérifiés par la plateforme, comme Googlebot ou Bingbot mentionnés dans l’interface.

La valeur par défaut est :

allow

Crawlers IA

Cette protection permet de traiter spécifiquement les crawlers IA. L’interface mentionne notamment ClaudeBot, GPTBot et Bytespider.

Une règle de sécurité personnalisée peut prendre le dessus si elle définit une règle plus spécifique pour un crawler.

Détection JS

La Détection JS injecte un challenge JavaScript léger et invisible afin de distinguer les navigateurs de l’automatisation.

La valeur par défaut est :

off

Ressources statiques

Cette option permet d’exempter les images, CSS et JavaScript de la lutte anti-bots.

La valeur par défaut est :

on

Comment configurer les En-têtes de sécurité ?

Les En-têtes de sécurité interviennent sur la réponse HTTP envoyée au navigateur. Ils ne constituent donc pas une nouvelle étape de filtrage dans l’ordre d’exécution des requêtes présenté au début de cet article.

Par défaut, Fasterize ajoute les en-têtes configurés lorsqu’ils sont absents. La valeur définie par l’origine n’est pas écrasée, sauf comportement spécifique par en-tête.

Le réglage Écraser les en-têtes d’origine permet de modifier ce comportement.

⚠️ CSP et COEP constituent deux exceptions : ils écrasent toujours la valeur d’origine, quel que soit l’état du réglage « Écraser les en-têtes d’origine ».

Comment configurer HSTS ?

HSTS — HTTP Strict Transport Security — permet de forcer le navigateur à utiliser HTTPS sur le domaine pendant la durée définie par max-age.

La console permet de configurer :

• l’activation et la durée max-age ;
• l’inclusion des sous-domaines ;
• HSTS preload.

⚠️ L’option preload est indiquée comme quasi irréversible dans la console. Le retrait des listes de preload des navigateurs peut prendre des mois et cette configuration verrouille les sous-domaines en HTTPS. Ne l’activez qu’en toute connaissance de cause.

Quels En-têtes de sécurité navigateur peut-on configurer ?

Shield propose plusieurs en-têtes destinés à renforcer le comportement du navigateur.

X-Content-Type-Options

X-Content-Type-Options empêche le MIME sniffing.

La valeur indiquée dans l’interface est :

nosniff

Referrer-Policy

Referrer-Policy contrôle les informations transmises dans l’en-tête Referer lors de la navigation vers une autre ressource ou un autre site.

Dans la configuration affichée, la valeur est :

strict-origin-when-cross-origin

X-Frame-Options

X-Frame-Options permet de contrôler l’affichage du contenu dans une frame et contribue à limiter certains scénarios de clickjacking.

Les choix visibles dans la console sont :

• désactivé ;
• SAMEORIGIN ;
• DENY.

L’interface indique par ailleurs que frame-ancestors dans CSP constitue son équivalent moderne.

Permissions-Policy

Permissions-Policy permet de restreindre l’accès du navigateur à certaines fonctionnalités, comme la caméra, le microphone ou la géolocalisation.

La configuration visible fournit notamment des exemples tels que :

camera=()

et :

microphone=()

Ces directives permettent de désactiver l’accès aux fonctionnalités correspondantes pour le périmètre défini.

Comment masquer les en-têtes d’empreinte ?

Shield permet de supprimer certains en-têtes susceptibles de divulguer des informations sur la technologie utilisée par le serveur.

L’interface mentionne notamment :

• X-Powered-By
• X-AspNet

💡 L’en-tête Server n’est pas supprimé par cette fonctionnalité : sa suppression est refusée par la plateforme. Si vous le voyez toujours dans la réponse HTTP, cela ne signifie donc pas que le masquage des en-têtes d’empreinte ne fonctionne pas.

À quoi servent les protections d’isolation cross-origin ?

Les protections COOP, CORP et COEP permettent d’encadrer les interactions entre votre page et des ressources ou contextes provenant d’autres origines.

Ces réglages doivent être activés progressivement : comme le précise la console, ils peuvent casser l’intégration de ressources tierces.

Cross-Origin-Opener-Policy (COOP)

COOP agit sur l’isolation du contexte de navigation vis-à-vis des fenêtres provenant d’autres origines.

La console mentionne la valeur :

same-origin

Cross-Origin-Resource-Policy (CORP)

CORP contrôle les origines autorisées à charger une ressource.

Les options visibles dans Shield sont :

• désactivé ;
• same-origin ;
• same-site ;
• cross-origin.

Le choix dépend donc du niveau de partage cross-origin attendu pour vos ressources.

Cross-Origin-Embedder-Policy (COEP)

COEP encadre l’intégration de ressources cross-origin dans vos pages.

Les choix visibles sont :

• désactivé ;
• Report-Only ;
• require-corp.

⚠️ COEP peut casser certaines intégrations tierces. Activez-le progressivement et vérifiez le comportement des ressources utilisées par votre site.

COEP fait par ailleurs partie des en-têtes qui écrasent toujours la valeur définie à l’origine.

Comment déployer progressivement une Content-Security-Policy ?

Content-Security-Policy, ou CSP, permet de définir les sources depuis lesquelles différentes ressources peuvent être chargées.

La console identifie explicitement cette configuration comme présentant un risque élevé.

Une politique trop restrictive peut en effet bloquer des scripts, des feuilles de style ou des images nécessaires au rendu de votre site.

Shield propose trois états :

• désactivé ;
• Report-Only ;
• Appliquer.

💡 Commencez en Report-Only. La politique n’est alors pas appliquée : les violations sont signalées, ce qui vous permet d’observer son comportement avant de passer en application.

Une fois les violations analysées et la politique ajustée, vous pouvez passer à son application.

⚠️ CSP écrase toujours sa valeur d’origine, indépendamment du réglage global « Écraser les en-têtes d’origine ».

Comment suivre l’activité de Shield ?

Le bouton Voir l’activité Shield permet d’accéder au suivi de l’activité des protections.

Les différentes vues doivent être distinguées afin d’interpréter correctement les informations présentées.

Client Reputation

La vue Client Reputation concerne les informations de réputation associées au trafic observé.

Les compteurs de réponses bloquées ou limitées ne doivent pas être attribués à cette vue.

Blocked & Throttled Responses

La vue Blocked & Throttled Responses permet de suivre les réponses associées aux requêtes bloquées ou limitées.

Elle permet notamment d’observer :

• les réponses HTTP 403 ;
• les réponses HTTP 429 ;
• les réponses HTTP 401 ;
• le volume total correspondant.

Cela permet de vérifier l’impact des protections après leur déploiement et d’identifier une éventuelle augmentation des blocages ou limitations.

Quelles bonnes pratiques appliquer pour configurer Shield ?

Shield permet de combiner plusieurs protections. Pour conserver une configuration lisible et éviter des effets de bord, procédez progressivement :

• commencez par comprendre l’ordre d’exécution des protections ;
• vérifiez l’ordre de vos Règles de sécurité ;
• utilisez log lorsque vous souhaitez observer les correspondances avant de modifier le traitement du trafic ;
• gardez en tête que log n’interrompt pas l’évaluation des règles suivantes ;
• utilisez skip de manière ciblée, car il peut contourner plusieurs protections situées en aval ;
• calibrez vos seuils de limitation de débit avant d'appliquer une action ;
• privilégiez des exceptions précises pour le WAF managé ;
• commencez CSP en Report-Only ;
• activez progressivement COOP, CORP et COEP ;
• vérifiez soigneusement votre configuration avant d’activer HSTS preload ;
• contrôlez l’activité Shield après chaque modification importante.

Conclusion

Shield permet de construire la posture de sécurité de votre site en combinant plusieurs briques indépendantes : Contrôle d’accès, Règles de sécurité, Limitation de débit, Règles managées, Bots & trafic automatisé et En-têtes de sécurité.

Pour configurer ces protections efficacement, trois réflexes sont essentiels : comprendre où chaque protection intervient, savoir quelle action elle applique et observer son comportement avant de renforcer progressivement la configuration.

L’ordre d’exécution mérite une attention particulière. Une Règle de sécurité utilisant skip, par exemple, peut avoir des conséquences sur plusieurs protections situées en aval. À l’inverse, une règle utilisant log permet d’observer le trafic tout en laissant l’évaluation se poursuivre.

En procédant progressivement et en surveillant l’activité après chaque changement, vous pouvez adapter Shield aux besoins réels de votre trafic.

‍