WAF nouvelle génération Fastly : tutoriel pour une application progressive et sûre

Publié le

14 juil. 2026

Mis à jour le

15 juil. 2026

Temps de lecture

19 min de lecture

Le WAF nouvelle génération Fastly peut identifier des signaux dans les requêtes et appliquer des actions par la configuration de politiques et de règles. Il ne remplace pas l'autorisation applicative, la validation des entrées, la protection de l'origine ni la réponse aux incidents. Traitez-le comme un contrôle de sécurité qui nécessite un responsable, un périmètre testé, une télémétrie utile et une application progressive.

À l'échelle où opère un orchestrateur d'edge managé — des dizaines d'espaces de travail, plusieurs origines, un trafic déjà façonné par plus d'un fournisseur — cette discipline ne peut pas rester un projet ponctuel : elle doit devenir un modèle opérationnel reproductible, avec un enregistrement unique et à jour de ce qui a changé, où et pourquoi. Le rôle d'Optimi est de garder ces changements de politique visibles et cohérents sur chaque propriété orchestrée, pas de prendre les décisions d'application à votre place.

Prérequis

Préparez les éléments suivants avant de modifier le comportement du WAF :

• L'accès au compte ou à l'espace de travail Fastly Next-Gen WAF propriétaire du site cible, ainsi que les propriétaires du service et de l'application capables de valider le trafic.
• Un inventaire à jour des domaines, chemins, API, points d'administration, intégrations approuvées, méthodes de déploiement et protections contre le contournement de l'origine.
• Une référence du trafic légitime : parcours utilisateur critiques, clients API, plages IP partenaires lorsque cela est justifié, trafic navigateur et bot, méthodes attendues et codes de réponse normaux.
• Une destination de logs ou une vue des événements WAF avec rétention, contrôle d'accès, horodatages, corrélation des requêtes et un processus d'examen des faux positifs.
• Un opérateur de restauration nommé et une courte procédure pour désactiver ou restreindre la politique ou règle candidate.

Ne collez pas d'identifiants de production, cookies de session, en-têtes d'authentification, données de paiement, données personnelles brutes ni corps de requête client réels dans un simulateur, ticket, webhook ou chat. Utilisez des valeurs synthétiques et masquez les échantillons avant de les partager.

Scénario Acme Shop

Acme Shop retire l'endpoint POST /api/legacy-cart. Le propriétaire de l'application confirme qu'aucun client actuel ne doit plus l'appeler. Le changement WAF est une règle de requête étroitement bornée pour le domaine shop.example.test, le chemin /api/legacy-cart et la méthode POST — démarrant avec l'action valide Ajouter un signal et une journalisation Échantillonnée, jamais un blocage large fondé sur un user-agent ou un pays. Cet exemple sert de fil rouge au reste du guide : un échantillon nettoyé est d'abord simulé, puis observé en staging, avant que la règle ne soit promue vers l'application, une fois le passage en caisse normal resté intact.

1. Établir le périmètre du WAF nouvelle génération Fastly avant d'ajuster les détections

Créez ou sélectionnez le site (espace de travail) et le déploiement qui protègent le trafic visé, en suivant les indications Fastly sur la configuration et la mise en place du Next-Gen WAF. Vérifiez la couverture réelle avec une requête contrôlée et les logs ; le seul nom d'une politique ou d'un espace de travail ne prouve pas que le nom d'hôte, le chemin de trafic ou l'intégration sont protégés.

Pour chaque politique, consignez :

• Les domaines et environnements qu'elle protège, et si la politique correspond à la production, au staging ou à un canari limité.
• Le déploiement et le chemin de requête, y compris le proxy ou service qui transmet le trafic au WAF.
• Le propriétaire de l'application, le responsable de la sécurité, les profils de trafic attendus et les flux métier protégés.
• Le responsable du changement, la fenêtre de revue, les métriques de succès et l'action de restauration.

Gardez les périmètres de développement, de staging et de production distincts. Une exception de test d'intégration permissive ou un endpoint de test bruyant ne doit pas devenir une exclusion de production non revue. Si une même application doit être traitée différemment par nom d'hôte ou route, définissez et vérifiez explicitement les limites plutôt que de supposer un héritage de politique.

2. Comprendre les signaux et les exclusions de signaux WAF

Les signaux sont des étiquettes que Fastly utilise pour des propriétés de requêtes associées à des attaques, anomalies, bots, API ou autres comportements. La détection des signaux et la réponse sont des décisions distinctes. Fastly indique que certains signaux système, dont les signaux de correctif virtuel CVE, API et de prise de contrôle de compte (ATO), doivent être activés avant de pouvoir être utilisés, et que les signaux API et ATO ne sont pas inclus dans le palier de plateforme Essential. Consultez Configurer les signaux système et Utiliser les signaux système.

Commencez par observer un petit ensemble de signaux pertinents pour la menace sur une route étroite. Comparez les signaux aux parcours connus comme fiables et à l'automatisation attendue. Consignez la forme de la requête, le signal, l'action, la réponse et l'effet métier, pas seulement le nombre.

Utilisez une exclusion de signal uniquement pour empêcher qu'un faux positif précis et compris soit étiqueté par un signal précis. Ce n'est pas une liste d'autorisation générale et elle peut réduire la détection future sur chaque requête correspondant à ses conditions. Le guide des règles d'exclusion de signal de Fastly explique que les exclusions empêchent les requêtes correspondantes d'être étiquetées avec le signal système spécifié, et que tous les signaux système ne sont pas admissibles à une exclusion : vérifiez la documentation propre à chaque signal avant de construire une exception autour de lui.

Rendez les exclusions aussi étroites que possible :

• Liez l'exclusion au seul signal qui a produit le faux positif.
• Limitez-la à des attributs stables qui expriment le cas sûr connu, comme un chemin et une méthode étroitement bornés, plutôt qu'à un site entier ou une chaîne user-agent large.
• Définissez un responsable, une raison, une date de création, un lien vers les preuves et une date de revue. Supprimez-la lorsque le comportement applicatif ou la détection est corrigé.
• Testez à nouveau la requête légitime visée et une requête malveillante ou malformée voisine afin que l'exception ne masque pas la classe de menace.

Fastly prend en charge les conditions de règle fondées sur les champs de requête et, pour les exclusions de signal, sur les champs propres au signal. Examinez les champs et opérateurs disponibles dans Définir les conditions de règle avant de fonder une protection sur un en-tête de proxy peu fiable ou un chemin à correspondance lâche.

3. Ajouter des règles de requête pour des décisions spécifiques et explicables

Utilisez une règle de requête lorsque vous pouvez énoncer en une phrase la condition, l'action visée, la population affectée et la condition de restauration. Par exemple : « Journaliser les requêtes vers cet endpoint obsolète avec cette méthode impossible pendant que nous confirmons qu'aucun client n'en dépend. » Ne commencez pas par un blocage global fondé uniquement sur un user-agent, un pays ou un en-tête non validé.

Fastly décrit les règles de requête comme des conditions de requête arbitraires associées à des actions WAF. Les actions et leur disponibilité peuvent différer selon les fonctionnalités du compte et le déploiement ; utilisez donc la documentation actuelle Travailler avec les règles de requête et À propos des règles plutôt que de copier une recette de configuration universelle.

Pour chaque règle de requête :

1. Définissez la plus petite combinaison de route, méthode, domaine ou signal qui exprime le risque.
2. Pour l'observation, utilisez l'action valide Ajouter un signal et réglez la journalisation de requête sur Échantillonnée. Log n'est pas une action de règle de requête : elle n'existe que pour les règles de limitation de débit avancée au niveau du site. Ne passez pas directement au blocage sur la base de correspondances théoriques.
3. Ajoutez un nom descriptif et un enregistrement du changement contenant le responsable, le ticket, le volume attendu, l'heure de début, l'heure de fin ou de revue et l'action de restauration exacte.
4. Testez les cas positifs, négatifs et limites. Une règle qui détecte correctement une requête fabriquée mais correspond à un client mobile normal n'est pas prête à être appliquée.
5. Examinez les logs de résultat avec le propriétaire de l'application avant d'élargir la condition ou l'action.

Évitez les règles qui reposent sur un en-tête d'identité fourni par le client, sauf si la frontière du proxy de confiance supprime les valeurs client et définit elle-même cet en-tête. Les décisions WAF ne peuvent pas corriger une origine qui accepte toujours du trafic direct et non authentifié.

Pour Acme Shop, la configuration d'observation retenue associe les conditions hôte = shop.example.test, chemin = /api/legacy-cart et méthode = POST à l'action Ajouter le signal ACME-LEGACY-CART-OBSERVED, avec une journalisation de requête échantillonnée et une date d'expiration correspondant à la fin de la fenêtre d'observation approuvée.

4. Utiliser le simulateur, puis valider sur du trafic réel progressif

Le simulateur Next-Gen WAF est utile pour vérifier les conditions et actions attendues sans envoyer un échantillon en production. Il peut indiquer si un échantillon serait bloqué ou journalisé, le code de réponse, les signaux ajoutés et les masquages. Fastly documente des limites importantes : le simulateur ne prend pas en charge la limitation de débit avancée, la déception ni la géolocalisation, et les déploiements Edge WAF peuvent différer de l'implémentation reverse-proxy du simulateur. Consultez Tester la logique de règle avec le Simulator.

Construisez une petite matrice de test avec des échantillons nettoyés :

• Une requête normale pour chaque route critique, incluant les en-têtes et méthodes attendus.
• Une requête qui doit correspondre au signal ou à la règle candidate.
• Une correspondance proche qui doit rester autorisée ou journalisée comme prévu.
• La forme d'un flux authentifié représentée par des valeurs de substitution, jamais un vrai token ou cookie.
• Un échantillon de réponse lorsque la condition ou la décision dépend d'informations de réponse.

La simulation est une vérification de logique, pas une preuve de production. Une fois réussie, déployez la politique ou règle candidate dans un environnement limité ou le périmètre de production sûr le plus étroit. Exercez des parcours synthétiques réels et des clients de test approuvés, puis comparez les événements WAF aux résultats applicatifs et d'origine.

Le simulateur a aussi des limites de reconstruction plus étroites à connaître avant de bâtir une matrice de test. Les corps de requête envoyés en multipart/form-data ou en text/csv ne sont pas reconstruits du tout : un endpoint de téléversement de fichier ou d'import CSV ne peut donc pas être représenté fidèlement par un échantillon synthétique, et doit être validé sur du trafic de staging. Un signal informatif encore actif à la fin du traitement d'une requête n'apparaît dans la sortie du simulateur que si la requête a été bloquée ou explicitement autorisée : son absence dans une exécution ne prouve donc pas qu'il ne s'est jamais déclenché — confirmez-le face aux événements de staging, pas au simulateur seul.

Pour Acme Shop, cela revient à simuler l'échantillon synthétique POST /api/legacy-cart dans Security > Next-Gen WAF > Simulator avec une réponse 204 d'exemple, sans jamais utiliser un vrai panier, token ou cookie, puis à confirmer que le résultat correspond bien à l'action Ajouter un signal attendue.

5. Rendre la journalisation utile sans collecter de données sensibles

Journalisez suffisamment pour répondre à ce qui s'est passé : horodatage, identité de politique ou règle, action, signal, nom d'hôte, route normalisée, ID de requête, état de réponse, version de déploiement et un identifiant de réseau client revu du point de vue de la confidentialité lorsque nécessaire. Corrélez les événements WAF avec la télémétrie de périphérie, d'origine et d'application à l'aide d'ID de requête ou de trace.

Appliquez une politique de minimisation des données aux logs WAF et aux outils en aval :

• N'exportez pas les en-têtes Authorization, les cookies, secrets, tokens d'accès, corps de formulaire bruts ni valeurs de requête sensibles.
• Évitez les URL complètes lorsque les chaînes de requête peuvent contenir des données personnelles ou d'identifiants ; utilisez une route normalisée ou un masquage approuvé.
• Limitez l'accès, la rétention et la transmission par webhook aux personnes et systèmes ayant un besoin documenté.
• Traitez les échantillons de revue de faux positifs comme des données opérationnelles sensibles. Masquez-les avant les tickets, chats, supports fournisseurs ou rapports d'incident.

Les indications Fastly sur la surveillance des signaux décrivent comment inspecter l'activité des signaux. Validez les champs disponibles, la latence de livraison et le comportement de masquage dans votre compte avant d'écrire une alerte ou un runbook d'investigation autour d'eux.

L'endroit où chercher ces données diffère selon le panneau de contrôle et le palier de plateforme : le Signals Dashboard du panneau Next-Gen WAF offre des graphiques chronologiques par site, tandis que la page Signals du panneau Fastly filtre plutôt par type (System, Configurable, Virtual Patch, Custom). Les comptes Essential n'ont que la page Signals, pas le Dashboard : construisez votre habitude de revue autour de la vue que possède réellement votre compte (voir plus loin la section sur les paliers de plateforme).

Réserves concernant les API et webhooks

Automatiser les changements de politique ou la livraison d'événements est utile, mais un token API ou un webhook est une frontière de sécurité de production. Ne supposez pas que chaque capacité de console, type de règle, champ d'événement ou garantie de livraison webhook est disponible via chaque API ou formule de compte.

• Utilisez des identifiants à privilèges minimaux, gérés séparément, et effectuez leur rotation selon une planification définie. Ne placez jamais de tokens de longue durée dans VCL, du code navigateur, le contrôle de source ou des URL de webhook.
• Rendez les changements pilotés par API idempotents là où l'API le permet, enregistrez les identifiants de politique ou de règle obtenus et conservez une étape de revue humaine pour les nouveaux comportements de blocage.
• Authentifiez les récepteurs de webhook, validez les signatures ou un autre mécanisme d'authenticité documenté lorsqu'il est disponible, imposez TLS et appliquez des protections contre la répétition, le débit et la taille des payloads.
• Concevez les consommateurs de webhook pour les événements dupliqués, retardés, manquants et désordonnés. Une alerte webhook ne doit pas être le seul enregistrement d'une action d'application.
• N'envoyez que les champs d'événement minimisés et approuvés. Un endpoint webhook n'est pas un lieu approprié pour les corps de requête, identifiants ou données de session client.

Confirmez le comportement des endpoints, l'authentification, les quotas, la pagination et le versionnement dans la référence API Next-Gen WAF actuelle de Fastly. Testez les intégrations avec un récepteur hors production avant de les utiliser pour une réponse automatisée.

6. Faire progresser la mise en application progressive NG-WAF

La mise en application progressive NG-WAF consiste à échanger l'observation contre des conséquences réelles, une porte à la fois, en s'appuyant sur des critères de promotion explicites plutôt que sur un déploiement déterminé uniquement par le calendrier :

1. Inventorier : vérifiez la couverture des politiques, les routes critiques, les responsables, la télémétrie et la référence connue comme fiable.
2. Détecter : activez ou observez les signaux pertinents sans introduire un nouveau blocage général. Étudiez les correspondances représentatives et les faux positifs.
3. Simuler : testez des échantillons nettoyés positifs, négatifs et limites par rapport aux conditions candidates.
4. Restreindre : appliquez une règle de requête candidate ou une exclusion de signal uniquement à la plus petite route, au plus petit environnement ou à la plus petite population de trafic sûre.
5. Appliquer : bloquez ou challengez seulement après que le taux de correspondance observé, l'impact sur les utilisateurs légitimes, les signaux de support, les erreurs applicatives et la restauration soient acceptables pour les responsables de la sécurité et de l'application.
6. Réviser : supprimez périodiquement les règles et exclusions temporaires, retestez les flux critiques et révisez les contrôles après les changements applicatifs ou les incidents.

À chaque étape, surveillez les résultats de sécurité et de produit : requêtes correspondantes et bloquées, erreurs WAF, erreurs d'origine, succès de connexion et de paiement, achèvement des API, latence, contacts au support et tentatives de contournement. Une baisse du nombre d'attaques peut signifier que la règle fonctionne, que le trafic a changé, que la journalisation a échoué ou que les utilisateurs ont été bloqués avant d'atteindre l'application.

Pour Acme Shop, le test positif attend l'événement prévu sans affecter le passage en caisse ; le test négatif attend qu'un GET /api/legacy-cart et qu'un POST /api/cart ne déclenchent aucun événement candidat. Toute régression du passage en caisse, correspondance inattendue ou hausse des erreurs d'origine met en pause la promotion. Ne promouvez qu'après une revue complète de la fenêtre de staging par les responsables applicatif et sécurité, et n'appliquez que le domaine, chemin et méthode observés.

Paliers de plateforme Fastly et limites de ressources du WAF nouvelle génération

Le WAF nouvelle génération Fastly est vendu selon trois paliers — Essential, Professional et Premier — et plusieurs capacités utilisées plus haut ne sont pas disponibles à chaque palier. Confirmez le palier actuel du compte avant de promettre une capacité qu'il n'a pas :

• La limitation de débit avancée, et l'action Log qui lui est propre, ne sont pas incluses à tous les paliers.
• Les signaux personnalisés, API et ATO sont indisponibles sur Essential : l'observation de la section 2 doit alors s'appuyer sur des signaux système.
• Le Signals Dashboard n'est pas disponible sur Essential ; utilisez la page Signals à la place.
• Les opérateurs Matches (regexp) et Is in list sont indisponibles sur Essential, ce qui limite la précision d'une règle ou d'une exclusion.

Des limites de ressources bornent aussi le nombre de règles qu'un corp ou un espace de travail peut porter : 1 000 règles de requête par corp plus 1 000 par site (les exclusions de signal comptent dans ce même quota), 15 règles de limitation de débit avancée par site, et 200 signaux personnalisés par corp plus 200 par site.

Comme les exclusions de signaux WAF partagent ce plafond, un espace de travail qui accumule des exclusions non documentées consomme son budget pour les futures règles : traitez la discipline de date de revue de la section 2 comme une gestion de capacité. Vérifiez les limites actuelles dans la référence Fastly des limites de ressources du WAF nouvelle génération avant de planifier un déploiement multi-espaces de travail.

Priorité des règles entre le corp et les espaces de travail

Le WAF nouvelle génération Fastly évalue les règles selon deux périmètres : le corp, qui s'applique à tous les espaces de travail du compte, et l'espace de travail (site), borné à une seule propriété. Fastly documente deux principes de priorité qui tranchent le résultat lorsque des règles se chevauchent :

1. Une action Allow prime toujours sur une action Block, quel que soit le périmètre. Une seule règle d'autorisation peut neutraliser un blocage qui se serait sinon déclenché sur la même requête.
2. Les règles au niveau du corp priment généralement sur les règles au niveau de l'espace de travail, sauf lorsque l'action de la règle au niveau de l'espace de travail est Allow — dans ce cas, l'autorisation au niveau de l'espace de travail l'emporte sur un blocage contradictoire au niveau du corp.

Cela devient sensible dès qu'une deuxième équipe ou propriété acquise partage le corp d'Acme Shop : un blocage ajouté au niveau du corp peut silencieusement neutraliser une décision d'application propre à un espace de travail, à moins que quelqu'un ne suive quel périmètre possède quelle règle. Avant de promouvoir la règle /api/legacy-cart d'Ajouter un signal vers Block, confirmez qu'aucune règle Allow au niveau du corp n'exempte déjà ce chemin, et consignez quel périmètre possède le changement.

Testez la priorité explicitement plutôt que de la déduire : mettez en scène ensemble les deux règles dans le simulateur ou en staging, et confirmez que l'action observée correspond à l'ordre documenté avant d'appliquer l'une ou l'autre en production.

Restauration

En cas d'incident de faux positif suspecté, privilégiez le rétablissement de l'accès légitime tout en préservant les preuves :

1. Arrêtez d'étendre l'application. Consignez les identifiants de politique et de règle, les horodatages, les ID de requête, les signaux observés, l'action, les routes affectées et l'impact client.
2. Désactivez ou restreignez uniquement la règle, l'action ou l'exclusion candidate en suivant le chemin de restauration prédéfini. Ne désactivez pas largement des protections non liées, sauf si l'incident l'exige.
3. Réexécutez des cas de test légitimes et semblables à une attaque contrôlés, puis vérifiez les parcours applicatifs, événements WAF, trafic d'origine et taux d'erreur.
4. Conservez les preuves nettoyées et mettez à jour l'enregistrement du changement. Corrigez la condition, le périmètre ou le comportement applicatif avant un nouveau déploiement progressif.
5. Si des données ont pu être exposées, ou si un identifiant ou un chemin d'origine peut être compromis, utilisez le processus d'incident de sécurité plutôt que de traiter l'événement comme un problème d'ajustement WAF.

Dépannage

• Le simulateur ne correspond pas : chemin, méthode ou casse différents de la règle. Comparez la requête synthétique à chaque condition, corrigez et resimulez.
• Le résultat du simulateur diffère du staging : déploiement différent ou fonctionnalité non prise en charge par le simulateur. Traitez les événements de staging comme la vraie porte de décision.
• Le passage en caisse est bloqué : le périmètre candidat a intercepté une requête légitime. Désactivez ou restreignez uniquement la règle candidate, puis retestez.
• Aucun événement WAF n'arrive : mauvais espace de travail, couverture insuffisante ou logs mal livrés. Envoyez un test contrôlé, suivez son ID de requête, puis corrigez avant toute décision d'application.
• Une règle ou une exclusion refuse de s'enregistrer : limite de règles atteinte pour le corp ou l'espace de travail (les exclusions de signaux WAF comptent dans ce quota). Retirez d'abord les exclusions expirées.
• Une fonctionnalité attendue est absente (signal personnalisé, action Log, Signals Dashboard) : compte probablement sur Essential. Confirmez le palier avant de vous engager sur la conception.
• Une règle Allow ne bloque pas un Block attendu : les conditions ne correspondent pas à la même requête, ou une règle de priorité supérieure a joué en premier. Comparez-les dans le simulateur, puis corrigez la règle Allow.

Pièges courants

• Traiter une exclusion de signal comme une liste d'autorisation : Elle supprime un signal spécifié pour les correspondances et peut créer un angle mort au-delà du faux positif initial.
• Bloquer avant d'observer le trafic réel : La réussite du simulateur ne prouve pas le comportement des vrais clients, chemins proxy, géolocalisation ou limites de débit.
• Utiliser des correspondances larges d'IP, pays, user-agent ou chemin : Elles sont facilement trop inclusives et peuvent bloquer des clients, partenaires, crawlers ou systèmes internes.
• Faire confiance aux en-têtes de transfert fournis par le client : À moins qu'un proxy de confiance ne les assainisse et ne les définisse, les clients peuvent les falsifier.
• Traiter les logs ou webhooks comme une télémétrie inoffensive : Ils peuvent contenir un contexte de requête sensible et être retardés, dupliqués ou indisponibles.
• Automatiser les blocages sans responsable de restauration : Un changement API rapide nécessite la même revue par les pairs, piste d'audit et voie de récupération qu'un changement de console.
• Supposer que le WAF protège une origine publiquement accessible : Restreignez et authentifiez séparément l'entrée de l'origine.
• Supposer que chaque fonctionnalité, opérateur et limite existe à tous les paliers : vérifiez le palier de plateforme du compte ainsi que le nombre actuel de règles et d'exclusions avant de concevoir un contrôle autour d'un signal personnalisé, d'une limitation de débit avancée ou d'une marge que le compte n'a pas.

Références Fastly principales

• Documentation Next-Gen WAF
• Configuration et mise en place du Next-Gen WAF
• Configurer les signaux système
• Travailler avec les règles d'exclusion de signal
• Travailler avec les règles de requête
• Définir les conditions de règle et limites du Simulator
• Surveillance des signaux
• Référence API Next-Gen WAF
• À propos des règles : types d'action et priorité
• Limites de ressources du WAF nouvelle génération