TL;DR

• Un WAF, ou Web Application Firewall, protège une application Web en analysant les requêtes HTTP et HTTPS avant qu’elles ne l’atteignent.
• Il applique des règles permettant de détecter ou de bloquer certaines requêtes malveillantes.
• Un WAF peut notamment contribuer à limiter les injections SQL, certains scripts intersites, les robots malveillants et les requêtes suspectes.
• Il fonctionne généralement comme une couche placée entre Internet et l’application.
• Un WAF n’est pas équivalent à un pare-feu réseau traditionnel.
• Les solutions peuvent être déployées dans le nuage, comme logiciel ou directement dans l’infrastructure.
• Un WAF complète le développement sécurisé, les mises à jour et les tests de sécurité. Il ne les remplace pas.

Une boutique en ligne québécoise reçoit des milliers de requêtes chaque jour.

La majorité provient de clients qui consultent des produits, remplissent un formulaire ou passent une commande.

Mais certaines requêtes peuvent avoir un objectif complètement différent : tester une vulnérabilité, injecter du code, contourner une authentification ou envoyer automatiquement des centaines de requêtes vers une même fonction.

Comment distinguer le trafic légitime des requêtes potentiellement malveillantes?

C’est précisément le rôle d’un WAF.

Un WAF analyse le trafic destiné à une application Web et applique des règles permettant de bloquer, mettre au défi ou surveiller certaines requêtes avant qu’elles n’atteignent l’application.

Qu’est-ce qu’un WAF?

WAF signifie Web Application Firewall, ou pare-feu applicatif Web.

Il s’agit d’un mécanisme de sécurité conçu spécifiquement pour les applications utilisant les protocoles HTTP et HTTPS.

OWASP décrit un WAF comme un pare-feu destiné aux applications HTTP. Il applique des règles aux échanges Web et peut notamment être utilisé pour protéger contre des attaques courantes telles que les injections SQL et les scripts intersites.

On peut le représenter simplement ainsi :

Utilisateur → WAF → application Web

Le WAF examine les requêtes avant qu’elles n’atteignent l’application.

Selon sa configuration, il peut :

• autoriser la requête;
• la bloquer;
• demander une vérification supplémentaire;
• la limiter;
• l’enregistrer pour analyse.

Le principe repose donc sur une inspection du trafic entrant et, dans certains cas, sortant.

Comment fonctionne un pare-feu applicatif Web?

Un WAF examine les caractéristiques d’une requête HTTP.

Il peut notamment analyser :

• l’adresse IP;
• l’URL demandée;
• les paramètres;
• les en-têtes;
• le corps de la requête;
• certains témoins;
• la fréquence des requêtes;
• la présence de motifs associés à des attaques connues.

Les solutions modernes reposent généralement sur un ensemble de règles.

Par exemple :

Si une requête contient une séquence correspondant à une injection SQL connue → bloquer.

Ou :

Si une même adresse envoie trop de requêtes vers une page de connexion → limiter ou mettre au défi.

Cloudflare explique que son WAF analyse les requêtes Web et API entrantes et les filtre à l’aide de jeux de règles pouvant tenir compte d’éléments comme l’adresse IP, le chemin URL, les en-têtes ou le contenu de la requête.

Où se place un WAF?

Le WAF se trouve généralement devant l’application.

Il agit donc comme une couche intermédiaire.

Imaginez une boutique en ligne :

Client

↓

Internet

↓

WAF

↓

Serveur Web

↓

Application

↓

Base de données

La requête passe d’abord par le WAF.

Si elle semble légitime, elle poursuit son chemin.

Si elle correspond à une règle de blocage, elle peut être arrêtée avant d’atteindre l’application.

Cette position explique pourquoi OWASP compare souvent le WAF à un mandataire inverse, puisqu’il se place du côté du serveur pour protéger une ou plusieurs applications Web.

Quelles attaques un WAF peut-il bloquer?

Les capacités varient selon le produit, les règles activées et la configuration.

Un WAF peut toutefois contribuer à limiter plusieurs catégories d’attaques.

Les injections SQL

Une injection SQL tente de manipuler une requête envoyée à une base de données.

Par exemple, un attaquant peut insérer une chaîne de caractères particulière dans un champ ou un paramètre afin de modifier la logique d’une requête SQL.

Les injections font toujours partie des risques importants recensés par OWASP dans son Top 10 des risques de sécurité applicative.

Un WAF peut détecter certains motifs associés à ces attaques et bloquer la requête.

Les scripts intersites

Les scripts intersites, ou XSS, cherchent à injecter du contenu actif dans une page Web.

Une application vulnérable pourrait par exemple afficher du contenu fourni par un utilisateur sans le traiter correctement.

Un WAF peut reconnaître certaines charges malveillantes connues et les empêcher d’atteindre l’application.

L’OWASP classe les faiblesses associées au XSS dans la catégorie des injections.

Les requêtes Web suspectes

Certaines requêtes ne correspondent pas exactement à une attaque connue, mais présentent des caractéristiques anormales.

Un WAF peut notamment repérer :

• des paramètres inhabituels;
• des séquences suspectes;
• des requêtes vers des fichiers sensibles;
• des en-têtes anormaux;
• des tentatives répétées sur certaines fonctions.

Les règles peuvent ensuite décider de bloquer ou simplement de surveiller ces requêtes.

Les robots malveillants

Les applications peuvent également recevoir du trafic automatisé.

Tous les robots ne sont pas nécessairement malveillants.

Certains servent à indexer les moteurs de recherche ou à effectuer des tâches légitimes.

D’autres peuvent toutefois servir à :

• tester des mots de passe;
• extraire automatiquement des données;
• créer de faux comptes;
• envoyer de nombreuses requêtes;
• tenter d’exploiter des vulnérabilités.

Certains WAF modernes intègrent des fonctions de détection des robots ou fonctionnent avec des outils spécialisés de gestion du trafic automatisé.

Cloudflare combine par exemple son WAF avec différents mécanismes de détection et de gestion du trafic, notamment des scores liés aux robots et aux attaques.

WAF et règles de sécurité

Un WAF repose largement sur ses règles.

Deux grandes catégories sont courantes.

Les règles gérées

Elles sont maintenues par le fournisseur ou une communauté spécialisée.

Elles peuvent être mises à jour lorsqu’une nouvelle menace ou vulnérabilité est découverte.

Cloudflare propose par exemple des règles gérées destinées à protéger contre des attaques connues et permet également la création de règles personnalisées.

Les règles personnalisées

Une organisation peut aussi créer ses propres règles.

Par exemple :

Bloquer certaines requêtes vers une page administrative provenant de l’extérieur du Canada.

Ou :

Limiter le nombre de tentatives vers une page de connexion.

Ces règles doivent être configurées avec prudence.

Une règle trop permissive laisse passer trop de trafic.

Une règle trop stricte peut bloquer de vrais utilisateurs.

Le problème des faux positifs

Un faux positif survient lorsqu’une requête légitime est considérée comme malveillante.

Imaginez un formulaire permettant à un développeur de coller du code.

Une règle du WAF pourrait interpréter certaines chaînes comme une tentative d’injection alors qu’elles font partie d’un contenu parfaitement légitime.

Il faut donc surveiller et ajuster les règles.

Certaines solutions permettent d’abord d’utiliser une règle en mode détection avant de passer au blocage.

Cette étape permet d’observer son comportement et de réduire le risque de bloquer inutilement des utilisateurs.

Quelle différence entre un WAF et un pare-feu réseau?

Les deux technologies utilisent le mot « pare-feu », mais elles ne travaillent pas au même niveau.

Un pare-feu réseau traditionnel analyse principalement les connexions réseau.

Il peut par exemple décider :

Autoriser le port 443.

Bloquer cette adresse IP.

Refuser cette connexion entrante.

Un WAF analyse plus précisément le contenu d’une requête Web.

Il peut donc distinguer deux requêtes utilisant toutes les deux HTTPS :

Requête A : consultation normale d’un produit

Requête B : tentative d’injection SQL

Le pare-feu réseau voit surtout une connexion HTTPS autorisée.

Le WAF analyse la requête au niveau de l’application.

On peut résumer ainsi :

Pare-feu réseau → protège le réseau

WAF → protège l’application Web

Les deux peuvent donc être complémentaires.

WAF infonuagique, logiciel ou matériel : quelle différence?

Les WAF peuvent être déployés de différentes façons.

WAF infonuagique

Les services de WAF infonuagique sont souvent placés entre Internet et le serveur de l’entreprise.

Le trafic passe par l’infrastructure du fournisseur avant d’atteindre le site.

Cette approche facilite notamment :

• le déploiement;
• la mise à jour des règles;
• la protection de plusieurs sites;
• l’intégration avec d’autres services de sécurité.

Cloudflare WAF constitue un exemple connu de cette approche.

Cloudflare indique que son WAF inspecte les requêtes HTTP et HTTPS en périphérie de son réseau avant qu’elles n’atteignent l’application.

WAF logiciel

Un WAF peut également être installé directement sur un serveur ou intégré à son infrastructure.

ModSecurity est un exemple important.

OWASP décrit ModSecurity comme un moteur de WAF libre pouvant filtrer les requêtes et réponses HTTP sur différentes plateformes, notamment Apache, IIS et Nginx.

Il est souvent utilisé avec le OWASP Core Rule Set, ou CRS.

WAF matériel

Certaines organisations utilisent également des appareils physiques dédiés placés dans leur infrastructure.

Cette approche peut offrir un contrôle poussé, mais implique généralement davantage de gestion, d’entretien et de coûts.

Elle est donc plus courante dans des environnements informatiques complexes.

Cloudflare WAF vs ModSecurity

Ces deux solutions répondent au même besoin général, mais leur fonctionnement et leur gestion sont différents.

Cloudflare WAF

Cloudflare WAF est un service infonuagique géré.

L’entreprise dirige son trafic vers l’infrastructure Cloudflare, où les requêtes peuvent être analysées avant d’atteindre son serveur.

Le service propose notamment :

• des règles gérées;
• des règles personnalisées;
• des mécanismes de limitation;
• des fonctions de détection;
• une intégration avec le réseau Cloudflare.

ModSecurity

ModSecurity est un moteur de WAF libre.

Il peut être utilisé directement avec des serveurs Web et doit être configuré avec des règles appropriées.

OWASP précise que ModSecurity est généralement associé au OWASP CRS, un ensemble de règles destiné à détecter différentes attaques HTTP courantes.

Le choix dépend donc notamment :

• de l’infrastructure;
• des compétences internes;
• du niveau de contrôle souhaité;
• du temps disponible pour la configuration;
• du budget.

Qu’est-ce que le OWASP Core Rule Set?

Le OWASP Core Rule Set, souvent appelé CRS, est un ensemble de règles génériques de détection d’attaques.

Il peut être utilisé avec ModSecurity et d’autres moteurs compatibles.

OWASP indique que le CRS vise à protéger les applications contre plusieurs catégories d’attaques courantes, notamment celles représentées dans le Top 10 OWASP, tout en limitant les fausses alertes.

On peut donc voir la relation ainsi :

ModSecurity = moteur

CRS = ensemble de règles

Le moteur inspecte le trafic.

Les règles lui indiquent quels comportements rechercher et quelles actions appliquer.

Un WAF peut-il protéger une boutique en ligne québécoise?

Oui, particulièrement lorsqu’un site expose des fonctions comme :

• un formulaire de connexion;
• un panier;
• une page de paiement;
• un formulaire de contact;
• une interface de programmation;
• un espace client.

Prenons une boutique en ligne montréalaise.

Un robot tente plusieurs centaines de requêtes sur la page de connexion.

Le WAF peut détecter ce comportement et appliquer une limitation.

Quelques minutes plus tard, une requête contenant un motif associé à une injection SQL arrive sur un formulaire.

Elle peut être bloquée.

En parallèle, les clients légitimes continuent d’utiliser le site normalement.

Le WAF ajoute ainsi une couche de protection entre Internet et l’application.

Un WAF protège-t-il WordPress?

Un WAF peut également être utile pour un site WordPress.

Il peut contribuer à bloquer certaines requêtes malveillantes avant qu’elles n’atteignent WordPress, ses extensions ou ses formulaires.

Mais il ne règle pas tous les problèmes.

Une extension vulnérable demeure vulnérable.

Un mot de passe faible demeure faible.

Une version obsolète demeure obsolète.

Le WAF peut parfois limiter l’exploitation d’une vulnérabilité, mais la correction doit toujours être effectuée.

Pour approfondir le sujet, consultez notre guide sur la sécurité WordPress.

Un WAF remplace-t-il les mises à jour?

Non.

C’est l’une des erreurs les plus importantes à éviter.

Un WAF peut offrir une protection temporaire contre certaines techniques d’exploitation.

On parle parfois de correctif virtuel lorsqu’une règle permet de bloquer l’exploitation d’une vulnérabilité avant que le logiciel soit corrigé.

Cloudflare propose notamment ce type de protection grâce à des règles capables de bloquer certaines tentatives d’exploitation connues.

Mais cela ne signifie pas que l’organisation peut ignorer la vulnérabilité.

La bonne approche reste :

Détecter → protéger → corriger → tester

Un WAF remplace-t-il le développement sécurisé?

Non plus.

Un WAF est une couche de défense supplémentaire.

Il ne corrige pas :

• une mauvaise logique d’autorisation;
• un mécanisme d’authentification mal conçu;
• des données mal protégées;
• une mauvaise gestion des sessions;
• toutes les failles de logique métier;
• un code vulnérable.

L’OWASP Top 10 est d’ailleurs présenté comme un point de départ pour aider les équipes à développer des applications plus sécurisées, pas comme une liste de problèmes qu’un WAF pourrait simplement masquer.

Une stratégie efficace de sécurité des applications Web combine donc :

développement sécurisé + mises à jour + tests + WAF + surveillance

Et les tests de sécurité?

Les tests restent indispensables.

Une équipe peut notamment utiliser :

• des analyses statiques;
• des tests dynamiques;
• des révisions manuelles;
• des tests de pénétration;
• des analyses de dépendances.

Ces méthodes servent à détecter et corriger les faiblesses directement dans l’application.

Le WAF intervient plutôt comme une couche de protection opérationnelle.

C’est une différence essentielle.

Comment déployer un WAF sans perturber le site?

Une organisation devrait généralement éviter de tout bloquer immédiatement.

Une approche progressive peut inclure :

1. Observer le trafic

Activez la détection et analysez les requêtes identifiées comme suspectes.

2. Examiner les faux positifs

Vérifiez si certaines règles bloqueraient des utilisateurs légitimes.

3. Ajuster les règles

Ajoutez des exceptions ou modifiez les seuils lorsque nécessaire.

4. Activer progressivement le blocage

Commencez par les catégories de trafic présentant le moins d’ambiguïté.

5. Surveiller en continu

Les applications changent.

Les attaques changent aussi.

Les règles doivent donc évoluer avec elles.

Le WAF est une couche, pas une stratégie complète

La WAF security peut améliorer considérablement la protection d’une application exposée à Internet.

Mais sa valeur dépend de sa configuration et de la façon dont elle s’intègre aux autres contrôles de sécurité.

Un WAF bien configuré peut :

détecter → filtrer → bloquer → enregistrer

Mais il ne peut pas garantir qu’une application est exempte de vulnérabilités.

Pour une organisation québécoise, la meilleure approche consiste donc à intégrer le WAF dans une stratégie plus large de sécurité.

Découvrez également comment protéger son site Web contre une cyberattaque.

Développez vos compétences en sécurité des applications Web

Comprendre le fonctionnement d’un WAF permet de mieux voir comment les applications peuvent être protégées une fois accessibles sur Internet.

Mais la sécurité applicative demande aussi de comprendre le développement sécurisé, les vulnérabilités, les tests, les mécanismes d’authentification et la surveillance.

Développez des compétences pratiques en développement Web sécurisé, tests d’applications et mécanismes de protection grâce à l’AEC Sécurité des applications Web du Collège Cumberland.

FAQ

Qu’est-ce qu’un WAF?

Un WAF, ou Web Application Firewall, est un pare-feu applicatif conçu pour analyser le trafic HTTP et HTTPS destiné à une application Web. Il applique des règles permettant de détecter, surveiller ou bloquer certaines requêtes potentiellement malveillantes.

Comment fonctionne un pare-feu applicatif Web?

Le WAF se place généralement entre Internet et l’application. Il inspecte les requêtes entrantes et applique des règles basées sur des éléments comme l’URL, les paramètres, les en-têtes ou le contenu envoyé.

Quelles attaques un WAF peut-il bloquer?

Selon les règles utilisées, un WAF peut notamment contribuer à bloquer certaines injections SQL, tentatives de scripts intersites, requêtes suspectes, robots malveillants et autres attaques HTTP.

Quelle est la différence entre un WAF et un pare-feu réseau?

Un pare-feu réseau contrôle principalement les connexions réseau, tandis qu’un WAF analyse plus précisément le contenu des requêtes destinées aux applications Web.

Un WAF suffit-il pour protéger une application Web?

Non. Un WAF constitue une couche de protection supplémentaire. Il doit être combiné avec du développement sécurisé, des mises à jour, des tests réguliers, une bonne gestion des accès et une surveillance appropriée.

Quelle est la différence entre Cloudflare WAF et ModSecurity?

Cloudflare WAF est un service infonuagique géré qui filtre le trafic sur le réseau Cloudflare. ModSecurity est un moteur de WAF libre pouvant être déployé sur différentes plateformes et utilisé avec des ensembles de règles comme le OWASP Core Rule Set