Un RSSI, un responsable Infrastructure Systèmes et Réseaux, et un commercial ne parlent pas tout le temps du même outil quand ils disent "firewall". Un DSI et un architecte sécurité ne cherchent pas la même chose quand ils comparent "WAF" et "WAAP". Ces termes circulent dans les mêmes conversations, le suffixe commun donne l'impression d'une famille cohérente. C'est trompeur, ils désignent parfois des réalités très différentes.
Le mot "firewall" est utilisé pour désigner des technologies qui n'ont en commun que l'idée générale de filtrer du trafic. Un firewall réseau et un WAF partagent le même suffixe mais opèrent à des niveaux radicalement différents du modèle OSI, sur des menaces distinctes, avec des logiques de détection opposées.
La confusion s'est accentuée avec l'émergence du "Next-Gen" et du WAAP, deux labels marketing qui recouvrent des réalités techniques précises mais sont souvent utilisés de façon interchangeable par les éditeurs pour désigner leurs produits.
Pour s'y retrouver, il faut repartir d'un principe simple : chaque outil protège une couche spécifique du modèle OSI, et la couche détermine les menaces qu'il peut voir, et donc bloquer.
Un outil ne peut analyser que ce qu'il voit. Un firewall réseau opérant aux couches 3 et 4 ne voit pas le contenu d'une requête HTTP. Il voit une adresse IP et un port. Une injection SQL, lui est invisible.
Couches 3 et 4 du modèle OSI
Le firewall réseau est la première ligne de défense d'une infrastructure. Il analyse le trafic entrant et sortant en se basant sur des critères réseau : adresses IP source et destination, ports TCP/UDP, protocoles. Il autorise ou bloque les flux selon des règles prédéfinies.
Son rôle est de contrôler qui peut communiquer, avec quoi sur le réseau. Il ne comprend pas ce que les communications contiennent. Un flux HTTP sur le port 443 lui paraît identique qu'il transporte une requête légitime ou une tentative d'injection SQL.
Il reste indispensable comme fondation de toute architecture sécurité, mais il ne protège pas les applications web contre les attaques applicatives.
Couche 7 du modèle OSI
Le WAF opère en proxy inverse entre Internet et l'application web. Il inspecte le contenu des requêtes HTTP et HTTPS, en cherchant des patterns caractéristiques d'attaques applicatives : injections SQL, Cross-Site Scripting (XSS), traversées de répertoires, inclusions de fichiers distants.
Contrairement au firewall réseau, il comprend le langage de l'application. Il peut analyser les paramètres d'une requête GET, le corps d'un POST, les en-têtes HTTP, et décider si leur contenu correspond à une attaque connue.
Le WAF classique fonctionne principalement par signatures et règles statiques, souvent basées sur les listes de l'OWASP Top 10. Cette approche est efficace contre les attaques connues, mais nécessite une maintenance continue des règles et génère parfois des faux positifs significatifs qui doivent être gérés manuellement.
Couche 7 avec analyse comportementale
Le Next-Gen WAF opère sur la même couche que le WAF classique, mais remplace ou complète la logique de signatures statiques par de l'analyse comportementale et du machine learning. Plutôt que de chercher des patterns d'attaques connus, il modélise le comportement normal du trafic et détecte les anomalies.
Cette approche présente deux avantages concrets. D'abord, elle permet de détecter des attaques inédites qui ne correspondent à aucune signature connue. Ensuite, elle réduit drastiquement les faux positifs, ce qui diminue la charge de maintenance manuelle. Des déploiements en mode blocage complet deviennent possibles dès le premier jour, sans période de calibration longue.
Dans un contexte où les exploits sont générés automatiquement par des outils d'IA, la capacité à détecter des comportements anormaux plutôt que des signatures connues devient un avantage structurel face à des attaques qui, par définition, n'ont jamais été vues auparavant.
Couche 7 avec analyse comportementale, protection unifiée applications et API
Le WAAP est le terme introduit par Gartner pour décrire une catégorie de solutions qui va au-delà du WAF classique. Il intègre en une seule plateforme quatre capacités distinctes : la protection des applications web (WAF), la protection des API, la gestion des bots, et la protection contre les attaques DDoS applicatives.
La distinction fondamentale avec le WAF tient à la protection des API. Le WAAP inclut la capacité d'analyser le comportement des API exposées et de détecter les abus. Une capacité que le WAF classique, conçu à l'origine pour le trafic web HTTP, ne couvre pas nativement.
Avec la prolifération des architectures microservices, des applications mobiles et des intégrations tierces, les API représentent aujourd'hui une surface d'attaque souvent plus large que les interfaces web traditionnelles. Concrètement, un WAF classique inspecte le trafic HTTP structuré. Une API REST moderne retourne du JSON, accepte des tokens d'authentification dans les headers, et expose des endpoints qui n'ont aucune équivalence dans le modèle de protection d'un WAF pensé pour du trafic web traditionnel. Le WAAP est conçu pour couvrir précisément cette réalité.
La question n'est plus "WAF ou WAAP ?" mais "quelle est ma surface d'attaque réelle, et quelle couche de protection couvre chaque partie de cette surface ?"
La plupart des organisations qui subissent une compromission via leur surface web n'ont pas nécessairement un firewall réseau mal configuré. Elles ont une couverture incomplète de leur couche applicative : des API non protégées, des applications exposées sans WAF, ou un WAF classique qui génère trop de faux positifs et finit par être désactivé ou mis en mode monitoring passif.
L'évolution vers des architectures cloud natives et API-first a élargi la surface applicative exposée sans que les outils de protection aient toujours suivi le même rythme. Un WAF déployé il y a cinq ans pour protéger un site web ne couvre pas les dizaines d'endpoints API qui ont été ajoutés depuis.
Le choix de l'outil n'est pas une décision technique isolée. C'est une question d'adéquation entre la surface réellement exposée et les couches de protection en place. La première étape est de connaître précisément ce que l'on expose, avant de décider comment le protéger.
La visibilité sur la surface d'attaque externe est le prérequis à toute décision de protection applicative.
Pour rendre ces distinctions concrètes, voici comment une attaque par injection SQL traverse chaque couche de protection, selon l'outil en place.
Un attaquant cible le formulaire de connexion d'une application web. Il envoie une requête HTTP contenant du code SQL malveillant dans le champ "identifiant" : au lieu d'un nom d'utilisateur, il saisit une instruction qui, si elle atteint la base de données, retournera tous les comptes sans mot de passe valide.
Ce scénario illustre deux choses. D'abord, que le firewall réseau ne remplace pas le WAF : ils opèrent sur des couches différentes et se complètent. Ensuite, que la différence entre WAF et WAAP devient critique dès qu'une API non documentée entre dans l'équation, ce qui est le cas dans la grande majorité des architectures modernes.
Le choix dépend de la nature de ce que vous exposez, des menaces prioritaires, et de la capacité opérationnelle disponible pour gérer la solution. Voici les situations les plus courantes.
Dans tous les cas, Firewall réseau et WAF (ou WAAP) ne s'excluent pas. L'un sécurise le périmètre réseau, l'autre protège la couche applicative. Les deux sont complémentaires pour une défense en profondeur. La bonne question n'est pas "quel outil choisir ?" mais "quelle partie de ma surface est couverte, et laquelle ne l'est pas encore ?"
Si vous vous posez ces questions sur votre propre infrastructure, c'est souvent le signe qu'il manque une étape en amont : savoir précisément ce que vous exposez à Internet, tel qu'un attaquant le voit. C'est cette visibilité que l'EASM apporte en continu, et c'est ce qui permet ensuite de positionner le bon niveau de protection au bon endroit. C'est la combinaison que nous mettons en oeuvre chez v6Protect.
Explorez nos guides et analyses sur les menaces actuelles.
