Plateforme Mis à jour le juillet 2026

Meilleur WAF pour Kong Gateway

Ajoutez une protection de pare-feu applicatif web à Kong Gateway. Comparez les plugins de sécurité Enterprise propres à Kong (Injection Protection, JSON/XML Threat Protection, Request Validator) aux moteurs tiers qui s'intègrent à Kong, dont open-appsec, Coraza (OWASP CRS) et ModSecurity.

Kong Gateway est l'une des passerelles d'API open source les plus déployées, bâtie sur OpenResty et NGINX et placée en frontal des API et des microservices dans les grandes entreprises. Parce qu'elle termine et route le trafic client avant qu'il n'atteigne vos services, et qu'elle assure déjà l'authentification, la limitation de débit et la transformation des requêtes, Kong est un point tout indiqué pour appliquer une politique de sécurité applicative.

Un point est à clarifier d'emblée : Kong n'a aucun plugin unique littéralement nommé « WAF ». Les recommandations WAF de Kong décrivent l'assemblage d'une couverture de pare-feu applicatif web à partir d'un ensemble de plugins de sécurité, plutôt qu'un module WAF monolithique. Plusieurs des plus pertinents, dont Injection Protection, JSON Threat Protection et XML Threat Protection, sont réservés à l'édition Enterprise ; d'autres, comme Bot Detection, IP Restriction et Rate Limiting, sont livrés avec Kong open source. Aucun des plugins natifs de Kong n'exécute l'OWASP Core Rule Set ; pour une couverture CRS, vous attachez un moteur tiers via l'architecture de plugins de Kong.

Ce guide compare les manières réalistes de placer un WAF sur Kong : les plugins de sécurité Enterprise natifs de Kong, le moteur d'apprentissage automatique open-appsec (qui livre un plugin Kong dédié), Coraza exécutant l'OWASP CRS via des intégrations communautaires Kong/OpenResty, et ModSecurity via le NGINX sous-jacent ou un sidecar. Il détaille aussi ce que Kong sait et ne sait pas faire nativement, afin que vous puissiez décider où le WAF doit se situer dans votre pile d'API.

Meilleurs fournisseurs WAF pour Kong Gateway

3

Coraza Web Application Firewall

OWASP CRS open source

Coraza est la voie open source pour exécuter l'OWASP Core Rule Set devant Kong. C'est un moteur moderne compatible ModSecurity écrit en Go sans dépendance C, et il exécute le CRS v4 (SQLi, XSS, injection de code, détection de scanners, et plus) ainsi que toute règle SecLang que vous apportez. Notez qu'il n'existe pas de plugin Kong officiel : Coraza atteint Kong via des plugins Lua communautaires ou une couche proxy-wasm/sidecar sur OpenResty ; validez donc l'intégration précise et épinglez les versions avant la production. Idéal lorsque vous voulez des règles CRS transparentes, standard du secteur, que vous contrôlez entièrement.

Avantages clés :

  • Exécute l'OWASP CRS v4 et les règles SecLang de ModSecurity
  • Moteur pur Go, sans dépendance C, facile à conteneuriser
  • Gratuit et open source (projet OWASP, Apache 2.0)
  • Se connecte via des intégrations communautaires Kong/OpenResty
Note : 4,2/5
Tarification : Gratuit et open source (Apache 2.0)
Offre gratuite
Lire l'avis complet Visiter le site
4

ModSecurity

Règles standard du secteur

ModSecurity est le moteur WAF éprouvé de longue date et l'origine du langage de règles SecLang et de l'écosystème OWASP CRS. Il n'existe pas de plugin Kong officiel ; comme Kong est bâti sur NGINX/OpenResty, les équipes exécutent généralement libmodsecurity via le connecteur NGINX ModSecurity sur le proxy sous-jacent, ou déploient ModSecurity en sidecar devant Kong. C'est un choix solide si votre équipe maintient déjà des règles SecLang, avec la contrepartie que l'intégration spécifique à Kong est autogérée plutôt qu'un plugin pris en charge et prêt à l'emploi.

Avantages clés :

  • Écosystème mature de règles SecLang et OWASP CRS
  • S'exécute sur le NGINX/OpenResty sous-jacent ou en sidecar
  • Gratuit et open source, sans coût de licence
  • Familier aux équipes migrant des règles ModSecurity existantes
Note : 4,0/5
Tarification : Gratuit (Open Source)
Offre gratuite
Lire l'avis complet Visiter le site

Ce qu'il faut rechercher dans un WAF pour Kong Gateway

Pour choisir comment ajouter un WAF à Kong Gateway, pesez les facteurs suivants :

  • Plugins natifs ou moteur tiers - Les plugins de type WAF propres à Kong s'exécutent en processus et s'intègrent proprement au routage et à l'authentification, mais les plus puissants (Injection Protection, JSON/XML Threat Protection, Request Validator) sont réservés à Enterprise. Les moteurs tiers comme open-appsec ou Coraza se connectent via l'architecture de plugins et peuvent être gratuits et open source.
  • Prise en charge de l'OWASP Core Rule Set - Les plugins natifs de Kong n'exécutent pas l'OWASP CRS. Si vous avez besoin d'une couverture CRS, prévoyez Coraza ou ModSecurity, qui exécutent directement les règles CRS/SecLang. Vérifiez la version du CRS (la v4 est l'actuelle) et la façon dont les mises à jour de règles sont livrées.
  • Licence Enterprise - Le plugin Injection Protection exige Kong Gateway 3.9+ et une licence Enterprise ; JSON Threat Protection exige 3.8+ et XML Threat Protection 3.1+, tous deux réservés à Enterprise. Confirmez le niveau requis par vos plugins avant de bâtir une conception autour d'eux.
  • Signatures/regex ou apprentissage automatique - Injection Protection et Bot Detection reposent sur des regex ; open-appsec repose sur le ML ; Coraza/ModSecurity sont des moteurs de règles CRS. Chacun présente des caractéristiques de réglage et de faux positifs différentes ; adaptez le moteur à votre modèle de menaces.
  • Limitation de débit et contrôle d'accès natifs - Kong fait déjà beaucoup avant tout WAF : Rate Limiting (et Rate Limiting Advanced en Enterprise), IP Restriction et Bot Detection traitent efficacement les abus et le contrôle d'accès dans la passerelle. Décidez ce qui doit être résolu par ces plugins par rapport à ce qui nécessite réellement une inspection du contenu.
  • Adresse IP client réelle - Si Kong est placé derrière un CDN ou un répartiteur de charge, configurez les IP de confiance et la gestion de X-Forwarded-For afin que le WAF, la restriction d'IP et les limites de débit voient la véritable adresse du client, et non celle du proxy amont.

Considérations Kong Gateway

Considérations propres à Kong lors du déploiement d'un WAF :

  • Kong open source n'a pas de plugin WAF applicatif - La passerelle gratuite livre Bot Detection, IP Restriction, Rate Limiting et Request Size Limiting, mais les plugins qui inspectent le contenu (Injection Protection, JSON/XML Threat Protection, Request Validator) sont réservés à Enterprise. Ne supposez pas que Kong open source inspecte le corps des requêtes à la recherche de SQLi ou de XSS ; il ne le fait pas sans un moteur ajouté.
  • Le WAF est une chaîne de plugins, pas un module unique - L'approche de Kong consiste à composer plusieurs plugins de sécurité dans la chaîne d'exécution. Planifiez l'ordonnancement (par exemple IP Restriction et Bot Detection tôt, Injection Protection et validateurs avant le proxying) pour que les rejets peu coûteux surviennent avant l'inspection coûteuse.
  • Pas d'OWASP CRS nativement - L'Injection Protection de Kong utilise ses propres motifs regex prédéfinis et personnalisés, et non l'OWASP CRS. Pour une couverture CRS/SecLang, vous attachez Coraza (intégration communautaire Kong/OpenResty) ou exécutez ModSecurity sur le NGINX sous-jacent ou en sidecar.
  • Bâti sur NGINX/OpenResty - Comme Kong s'exécute sur OpenResty, vous pouvez ajouter des plugins WAF à base de Lua tels que le rattachement open-appsec, ou recourir au connecteur NGINX ModSecurity au niveau du proxy. Cette flexibilité est réelle, mais les voies non natives sont autogérées.
  • Konnect Dedicated Cloud Gateways - Kong ne fournit pas de WAF natif pour les Dedicated Cloud Gateways. Comme les Dedicated Cloud Gateways publics exposent un nom d'hôte DNS plutôt que des IP statiques, Kong recommande d'apporter votre propre WAF en attachant un CDN prenant en charge les origines basées sur DNS et capable de porter une politique WAF (le guide sur le réseau public de Kong cite Amazon CloudFront avec AWS WAF, Azure Front Door avec Azure WAF, Cloudflare et Fastly avec Next-Gen WAF) devant la passerelle comme défense de couche 7 de première ligne. Lorsque le CDN publie des plages d'IP de sortie statiques, associez-le au plugin IP Restriction pour autoriser ces IP en liste blanche. Il s'agit d'un contrôle tiers fourni par le client, et non d'un WAF fourni par Kong.
  • Forme de déploiement - Les mêmes plugins s'exécutent sur Linux/Docker auto-hébergé, sur Kubernetes via le Kong Ingress Controller (géré par CRD), en mode hybride avec un plan de contrôle dans le cloud et des plans de données autogérés, ainsi que sur Konnect. La politique WAF voyage avec votre configuration Kong déclarative.

Questions fréquentes

Kong Gateway open source inclut-il un WAF ?

Pas un WAF applicatif complet. Kong open source livre des plugins de sécurité comme Bot Detection, IP Restriction, Rate Limiting et Request Size Limiting, qui traitent les bots, le contrôle d'accès et les abus. Les plugins qui inspectent le contenu pour détecter l'injection SQL et le XSS, tels qu'Injection Protection et JSON/XML Threat Protection, sont réservés à Enterprise. Pour une inspection du contenu en open source, vous attachez un moteur tiers comme open-appsec ou Coraza.

Comment ajouter un WAF à Kong Gateway ?

Trois approches principales. Premièrement, les plugins Kong Enterprise : activez Injection Protection, JSON Threat Protection, XML Threat Protection et Request Validator, qui s'exécutent dans la passerelle. Deuxièmement, un plugin Kong tiers : le moteur ML open-appsec livre un plugin Kong dédié à base de Lua. Troisièmement, un moteur OWASP CRS : exécutez Coraza via une intégration communautaire Kong/OpenResty, ou ModSecurity sur le NGINX sous-jacent ou en sidecar. Votre choix dépend de la présence d'une licence Enterprise et du besoin de règles CRS.

Kong Gateway dispose-t-il d'un plugin nommé « WAF » ?

Non. Il n'existe pas de plugin Kong unique nommé « WAF ». La documentation WAF de Kong décrit la construction d'une couverture de pare-feu applicatif web à partir d'une combinaison de plugins, dont Injection Protection, JSON et XML Threat Protection, Request Validator, Bot Detection, IP Restriction et Rate Limiting, plutôt que la livraison d'un module WAF monolithique. Pour les Konnect Dedicated Cloud Gateways publics, Kong ne fournit pas de WAF natif ; il recommande plutôt d'attacher un WAF tiers au niveau du CDN (comme AWS WAF, Azure WAF, Cloudflare ou Fastly) devant la passerelle comme contrôle de couche 7 fourni par le client.

Le WAF de Kong prend-il en charge l'OWASP Core Rule Set ?

Non. Le plugin natif Injection Protection de Kong utilise ses propres motifs regex prédéfinis et personnalisés pour la détection de SQLi, XSS, SSI, XPath et exceptions Java, et non l'OWASP CRS. Pour exécuter le CRS (v4) sur Kong, vous attachez Coraza via une intégration communautaire Kong/OpenResty, ou exécutez ModSecurity sur le NGINX sous-jacent ou en sidecar. Les deux exécutent directement les règles CRS et SecLang.

Que fait le plugin Injection Protection de Kong ?

C'est un plugin Enterprise (Kong Gateway 3.9+) qui effectue une correspondance regex pour les motifs d'injection courants. Seule l'injection SQL est vérifiée par défaut ; vous activez le cross-site scripting, les server-side includes, XPath, les exceptions Java et les autres types prédéfinis via le paramètre injection_types, avec la prise en charge de regex personnalisées. Il inspecte les en-têtes de requête, les paramètres de chemin et de requête, ainsi que le corps de la charge utile, selon la configuration, et bloque une correspondance en renvoyant un statut 400 tout en journalisant le type d'injection et le motif correspondant. Consultez la référence Injection Protection pour la configuration complète.

Puis-je utiliser open-appsec, Coraza ou ModSecurity avec Kong ?

Oui. open-appsec livre un plugin Kong Gateway dédié, open source, à base de Lua (Beta) qui ajoute une détection des menaces par apprentissage automatique, installable via LuaRocks, Docker Compose ou une image de conteneur Kong. Coraza exécute l'OWASP CRS via des intégrations communautaires Kong ou OpenResty. ModSecurity s'exécute sur le NGINX sous-jacent via son connecteur ou en sidecar. Wallarm propose également une intégration Kong native pour la sécurité des API. Seuls open-appsec et les propres plugins Enterprise de Kong sont de véritables plugins Kong ; les moteurs CRS sont des intégrations autogérées.

Puis-je limiter le débit et bloquer le trafic malveillant dans Kong sans WAF ?

Oui, jusqu'à un certain point. Le plugin Rate Limiting de Kong (et Rate Limiting Advanced en Enterprise) limite les débits de requêtes par service, route ou consommateur ; IP Restriction applique des listes CIDR d'autorisation/refus ; et Bot Detection bloque les bots connus par regex sur le User-Agent en renvoyant un code 403. Cela traite efficacement les abus et le contrôle d'accès dans la passerelle. Ce que ces plugins ne font pas, c'est inspecter le contenu des requêtes à la recherche d'injection ou de XSS, ce pour quoi un plugin ou un moteur WAF est nécessaire.

Plugins Kong Enterprise ou moteur WAF open source, lequel choisir ?

Les plugins Enterprise de Kong (Injection Protection, JSON/XML Threat Protection, Request Validator) s'exécutent en processus sans saut supplémentaire et se gèrent avec le reste de votre configuration Kong, mais ils exigent une licence commerciale et n'exécutent pas l'OWASP CRS. Un moteur open source, open-appsec pour la détection ML ou Coraza pour les règles CRS, est gratuit et vous offre soit un ML comportemental, soit des règles CRS/SecLang transparentes que vous contrôlez entièrement, au prix d'une intégration autogérée. Choisissez les plugins Enterprise pour une intégration Kong étroite et le support ; choisissez open-appsec ou Coraza lorsque le budget, la détection ML ou la transparence du CRS priment.