Guide de configuration WAF : protéger un site sans bloquer les utilisateurs

Configurez un WAF par étapes : cartographiez l’application, activez une base maintenue, observez les correspondances, testez des requêtes représentatives, ajoutez des exceptions étroites et n’appliquez les blocages qu’après avoir compris les faux positifs. Évitez de commencer avec une énorme liste de blocage ou de passer toutes les règles en mode blocage dès le premier jour. Un WAF doit réduire le trafic d’exploitation tout en préservant les navigateurs, API, robots d’indexation, partenaires et flux internes légitimes.

Un WAF fonctionne à la couche applicative HTTP. Il peut inspecter les méthodes, chemins, en-têtes, chaînes de requête, cookies et corps de requête pour repérer des signaux associés à des attaques telles que l’injection SQL, le cross-site scripting, la traversée de répertoires, l’injection de commandes et des composants connus comme vulnérables. Il ne remplace pas le code sécurisé, les correctifs, l’authentification, l’autorisation, la gestion des secrets, la limitation de débit ou la protection DDoS.

Commencez par une cartographie de l’application

Répertoriez les noms d’hôte publics, versions d’API, méthodes, types de contenu, flux d’authentification, endpoints d’upload, webhooks, chemins d’administration, intégrations partenaires et clients attendus. Identifiez les routes qui acceptent du JSON, XML, des formulaires multipart, GraphQL ou du texte enrichi. Consignez les codes de réponse et volumes de trafic normaux par route. Cet inventaire vous donne une base pour la politique comme pour les tests.

Séparez le trafic selon le risque et l’impact métier. Les endpoints de connexion, réinitialisation de mot de passe, paiement, modification de compte et administration nécessitent des contrôles plus stricts que les pages produit publiques. Les API peuvent nécessiter une validation de schéma et des limites de débit par client en plus de l’inspection WAF. Les endpoints de recherche et d’upload génèrent souvent des charges inhabituelles mais légitimes et sont des sources fréquentes de faux positifs.

Placez le WAF devant l’origine et vérifiez que celle-ci ne peut pas être atteinte via un nom d’hôte non protégé ou une adresse divulguée. Préservez la véritable IP client via le mécanisme de confiance du fournisseur et assurez-vous que les journaux applicatifs ne font pas aveuglément confiance à un en-tête de transfert fourni par le client. Définissez délibérément les limites TLS, d’en-tête d’hôte, de taille de corps, de délai d’attente et d’upload.

Construisez une politique en couches

1. Utilisez un jeu de règles gérées et maintenues. Sélectionnez des règles pertinentes pour les technologies et frameworks que vous utilisez réellement. Un jeu maintenu évolue avec les nouvelles vulnérabilités ; il ne dispense pas de connaître votre stack.

2. Ajoutez des règles personnalisées à forte confiance. Bloquez les chemins clairement malveillants, les méthodes impossibles, les sondes d’exploitation connues et les requêtes qui enfreignent votre contrat public. Lorsque c’est possible, faites correspondre plusieurs signaux au lieu de bloquer un unique user-agent ou pays.

3. Appliquez une action graduée. Utilisez le journal ou l’alerte pour la découverte, un challenge géré ou non interactif pour le trafic navigateur suspect lorsque c’est approprié, et le blocage pour les requêtes malveillantes à forte confiance. Les API et clients automatisés peuvent ne pas réussir les challenges navigateur ; utilisez donc à la place l’authentification, les jetons, l’identité IP ou réseau et les limites de débit.

4. Ciblez les règles. Appliquez une règle d’administration au chemin d’administration, une règle d’API à l’hôte API et une règle d’upload aux endpoints d’upload. Un périmètre étroit réduit à la fois le bruit de traitement et le rayon d’impact d’une erreur.

5. Créez des exceptions précises. Excluez une règle, un paramètre, un chemin ou une intégration de confiance spécifique uniquement lorsque le comportement de l’application l’exige. Préférez une exception à la désactivation de l’ensemble du jeu de règles gérées. Conservez une trace de la raison d’être de l’exception.

Les équivalents Cloudflare comprennent le Cloudflare Managed Ruleset, les règles WAF personnalisées, le managed challenge, les actions de journalisation, les règles de surcharge et les exceptions ciblées. Cloudflare avertit explicitement qu’il ne faut pas activer indistinctement toutes les règles disponibles, car les règles désactivées par défaut peuvent affecter le trafic légitime. Les équivalents Fastly comprennent le Next-Gen WAF, les règles de requête, les exclusions de signaux, les actions personnalisées, la journalisation d’échantillons de requêtes et son simulateur de requêtes. Les noms exacts des actions et l’ordre d’évaluation diffèrent : testez donc la configuration du fournisseur plutôt que de recopier une politique telle quelle.

Déployez sans perturber les utilisateurs

Utilisez un jeu de tests représentatif avant l’application des blocages. Incluez des requêtes navigateur normales, des parcours mobile et desktop, des URL localisées, des clients API, des webhooks signés, des retours de paiement, des uploads, des termes de recherche, des caractères encodés, des corps volumineux mais valides et des cas de test de sécurité connus dans un environnement hors production. Incluez les requêtes de vrais partenaires si leur trafic est contractuellement autorisé pour les tests.

Pour Cloudflare, déployez les règles gérées et utilisez le journal ou une action non bloquante ciblée pendant l’examen des correspondances. Pour Fastly, utilisez le simulateur Next-Gen WAF et les règles de requête pour tester la logique avant la production ; conservez une journalisation des requêtes correspondantes adaptée aux exigences de confidentialité. Sur les deux plateformes, capturez l’ID de règle, l’action, le nom d’hôte, le chemin, la méthode, la catégorie de client, le pays, l’ID de requête et le statut de réponse. Ne journalisez pas les identifiants, jetons, données de paiement ou charges sensibles non expurgées dans leur intégralité.

Examinez les faux positifs selon leur impact métier, et non uniquement leur nombre. Une règle qui correspond à un seul callback de réinitialisation de mot de passe peut être plus importante qu’une règle qui correspond à des milliers de sondes inoffensives. Demandez-vous si la requête est réellement nécessaire, si l’application peut normaliser son entrée ou si la politique doit être resserrée. N’ajoutez une exception qu’après avoir répondu aux deux premières questions.

Déployez les changements par petits lots. Annoncez le changement, capturez une version de configuration, désignez un responsable, surveillez les parcours clients et conservez un chemin de retour en arrière. Testez de nouveau après les mises à jour du jeu de règles gérées, car un fournisseur peut ajouter ou modifier des détections au fil du temps.

Testez et observez en continu

Mesurez les requêtes bloquées, soumises à un challenge, journalisées, autorisées et en erreur d’origine par règle, route, catégorie de client et version de déploiement. Suivez la réussite de connexion, la finalisation des paiements, les taux d’erreur API, la livraison des webhooks, la latence et les tickets de support en parallèle des détections de sécurité. Une baisse soudaine du trafic ne prouve pas une meilleure sécurité ; elle peut indiquer une intégration cassée.

Utilisez des contrôles synthétiques pour les parcours les plus importants et des canaris pour les changements de politique. Testez avec des chaînes d’attaque sûres dans un environnement contrôlé et ne lancez jamais de trafic non approuvé contre un tiers. Consultez les journaux WAF avec les journaux applicatifs afin de distinguer une requête bloquée d’un rejet par l’origine ou d’un échec côté client.

Les erreurs courantes consistent à faire confiance aux chaînes user-agent comme identité, à autoriser durablement chaque IP de bureau, à placer des règles d’autorisation larges avant l’inspection, à ignorer IPv6, à oublier les clients API non navigateurs, à journaliser des charges sensibles, à utiliser des challenges sur les webhooks et à laisser les exceptions temporaires indéfiniment. Un WAF géré doit compléter la limitation de débit et la protection DDoS, non les remplacer.

Pour des conseils d’implémentation, consultez la documentation du Cloudflare Managed Ruleset et la référence du simulateur WAF de Fastly. Pour une revue de politique conciliant sécurité et disponibilité, contactez Optimi.

Il n’existe que deux problèmes difficiles en informatique : l’invalidation du cache et le choix des noms.