Best WAF for Kong Gateway
Add web application firewall protection to Kong Gateway. Compare Kong's own Enterprise security plugins (Injection Protection, JSON/XML Threat Protection, Request Validator) against third-party engines that plug into Kong, including open-appsec, Coraza (OWASP CRS), and ModSecurity.
Kong Gateway is one of the most widely deployed open source API gateways, built on OpenResty and NGINX and sitting in front of APIs and microservices at large-scale enterprises. Because it terminates and routes client traffic before it reaches your services, and already runs authentication, rate limiting, and request transformation, Kong is a natural place to enforce application-layer security policy.
One thing to be clear about up front: Kong has no single plugin literally called "WAF." Kong's own WAF guidance describes assembling web application firewall coverage from a set of security plugins rather than a monolithic WAF module. Several of the most relevant ones, including Injection Protection, JSON Threat Protection, and XML Threat Protection, are Enterprise-only; others, such as Bot Detection, IP Restriction, and Rate Limiting, ship with open source Kong. None of Kong's native plugins run the OWASP Core Rule Set; for CRS coverage you attach a third-party engine through Kong's plugin architecture.
This guide compares the realistic ways to put a WAF on Kong: Kong's native Enterprise security plugins, the open-appsec machine-learning engine (which ships a dedicated Kong plugin), Coraza running the OWASP CRS through community Kong/OpenResty integrations, and ModSecurity via the underlying NGINX or a sidecar. It also covers what Kong can and cannot do natively so you can decide where the WAF belongs in your API stack.
Top WAF Providers for Kong Gateway
Kong Gateway WAF
Native Enterprise PluginsKong's own security plugins are the most natural fit for teams already standardized on Kong Gateway, because they run in-process alongside routing, auth, and rate limiting with no extra proxy hop. The Enterprise Injection Protection plugin (Kong Gateway 3.9+) checks SQL injection patterns out of the box and adds cross-site scripting, server-side includes, XPath, and Java-exception detection when you enable them via injection_types, across headers, path, query, and body, and blocks matches with a 400. JSON and XML Threat Protection cap payload depth and size, and Request Validator enforces request schemas. The catch is that these are Enterprise-only and Kong runs no OWASP CRS, so budget and rule-transparency expectations matter.
Key Benefits:
- Runs in-process in Kong, no separate WAF appliance or extra hop
- Injection Protection covers SQLi, XSS, SSI, XPath, and Java patterns
- JSON/XML Threat Protection and Request Validator harden API payloads
- Managed declaratively alongside routes via the same Kong config
open-appsec
Best ML Kong Pluginopen-appsec is the most first-class third-party WAF for Kong because it ships a dedicated, Lua-based Kong Gateway plugin (currently Beta) rather than a generic workaround. It is open source and uses machine-learning behavioral models instead of signature databases, so it aims at both known and zero-day web attacks without the false-positive tuning that regex rulesets demand. It installs via LuaRocks, Docker Compose, or a Kong container image, and supports DB-less declarative, DB, and Kong Konnect deployments. A strong option when you want ML-driven protection but do not want to pay for Kong Enterprise plugins.
Key Benefits:
- Dedicated open source Kong Gateway plugin (Lua-based, Beta)
- Machine-learning detection, no signature database to maintain
- Installs via LuaRocks, Docker Compose, or a Kong container image
- Works with DB-less, DB-backed, and Kong Konnect deployments
Coraza Web Application Firewall
Open Source OWASP CRSCoraza is the open source path to running the OWASP Core Rule Set in front of Kong. It is a modern, ModSecurity-compatible engine written in Go with no C dependencies, and it executes CRS v4 (SQLi, XSS, code injection, scanner detection, and more) plus any SecLang rules you bring. Note that there is no official Kong plugin: Coraza reaches Kong through community Lua plugins or a proxy-wasm/sidecar layer on OpenResty, so validate the specific integration and pin versions before production. Best when you want transparent, industry-standard CRS rules you fully control.
Key Benefits:
- Runs the OWASP CRS v4 and ModSecurity SecLang rules
- Pure Go engine, no C dependencies, easy to containerize
- Free and open source (OWASP project, Apache 2.0)
- Attaches via community Kong/OpenResty integrations
ModSecurity Open Source WAF
Industry Standard RulesModSecurity is the long-established, battle-tested WAF engine and the origin of the SecLang rule language and OWASP CRS ecosystem. There is no official Kong plugin; because Kong is built on NGINX/OpenResty, teams typically run libmodsecurity through the NGINX ModSecurity connector on the underlying proxy, or deploy ModSecurity as a sidecar in front of Kong. It is a solid choice if your team already maintains SecLang rules, with the trade-off that the Kong-specific integration is self-managed rather than a supported, drop-in plugin.
Key Benefits:
- Mature SecLang and OWASP CRS rule ecosystem
- Runs on the underlying NGINX/OpenResty or as a sidecar
- Free and open source, no licensing cost
- Familiar to teams migrating existing ModSecurity rules
What to Look For in a WAF for Kong Gateway
When choosing how to add a WAF to Kong Gateway, weigh these factors:
- Native plugins vs a third-party engine - Kong's own WAF-style plugins run in-process and integrate cleanly with routing and auth, but the strongest ones (Injection Protection, JSON/XML Threat Protection, Request Validator) are Enterprise-only. Third-party engines like open-appsec or Coraza attach through the plugin architecture and can be free and open source.
- OWASP Core Rule Set support - Kong's native plugins do not run the OWASP CRS. If you need CRS coverage, plan for Coraza or ModSecurity, which run CRS/SecLang rules directly. Confirm the CRS version (v4 is current) and how rule updates are delivered.
- Enterprise licensing - The Injection Protection plugin requires Kong Gateway 3.9+ and an Enterprise license; JSON Threat Protection requires 3.8+ and XML Threat Protection 3.1+, both Enterprise. Confirm which tier your plugins need before building a design around them.
- Signature/regex vs machine learning - Injection Protection and Bot Detection are regex-based; open-appsec is ML-based; Coraza/ModSecurity are CRS rule engines. Each has different tuning and false-positive characteristics, so match the engine to your threat model.
- Native rate limiting and access control - Kong already does a lot before any WAF: Rate Limiting (and the Enterprise Rate Limiting Advanced), IP Restriction, and Bot Detection handle abuse and access control efficiently in-gateway. Decide what to solve with those versus what genuinely needs payload inspection.
- Real client IP - If Kong sits behind a CDN or load balancer, configure trusted IPs and X-Forwarded-For handling so the WAF, IP restriction, and rate limits see the true client address, not the upstream proxy's.
Kong Gateway Considerations
Kong-specific considerations when deploying a WAF:
- Open source Kong has no application-layer WAF plugin - The free gateway ships Bot Detection, IP Restriction, Rate Limiting, and Request Size Limiting, but the payload-inspecting plugins (Injection Protection, JSON/XML Threat Protection, Request Validator) are Enterprise-only. Do not assume open source Kong inspects request bodies for SQLi or XSS; it does not without an added engine.
- WAF is a plugin chain, not one module - Kong's approach is to compose several security plugins in the execution chain. Plan the ordering (for example IP Restriction and Bot Detection early, Injection Protection and validators before proxying) so cheap rejects happen before expensive inspection.
- No OWASP CRS natively - Kong's Injection Protection uses its own predefined and custom regex patterns, not the OWASP CRS. For CRS/SecLang coverage you attach Coraza (community Kong/OpenResty integration) or run ModSecurity on the underlying NGINX or as a sidecar.
- Built on NGINX/OpenResty - Because Kong runs on OpenResty, you can add Lua-based WAF plugins such as the open-appsec attachment, or reach for the NGINX ModSecurity connector at the proxy layer. This flexibility is real, but the non-native paths are self-managed.
- Konnect Dedicated Cloud Gateways - Kong does not provide a native WAF for Dedicated Cloud Gateways. Because public Dedicated Cloud Gateways expose a DNS hostname rather than static IPs, Kong recommends bringing your own WAF by attaching a CDN that supports DNS-based origins and can carry WAF policy (Kong's public network guide names Amazon CloudFront with AWS WAF, Azure Front Door with Azure WAF, Cloudflare, and Fastly with Next-Gen WAF) in front of the gateway as first-line Layer 7 defense. Where the CDN publishes static egress IP ranges, pair it with the IP Restriction plugin to allowlist those IPs. This is a customer-supplied third-party control, not a Kong-provided WAF.
- Deployment shape - The same plugins run across self-hosted Linux/Docker, Kubernetes via the Kong Ingress Controller (managed through CRDs), hybrid mode with a cloud control plane and self-managed data planes, and Konnect. WAF policy travels with your declarative Kong config.
Frequently Asked Questions
Does open source Kong Gateway include a WAF?
Not a full application-layer WAF. Open source Kong ships security plugins like Bot Detection, IP Restriction, Rate Limiting, and Request Size Limiting, which handle bots, access control, and abuse. The payload-inspecting plugins that catch SQL injection and XSS, such as Injection Protection and JSON/XML Threat Protection, are Enterprise-only. For open source payload inspection you attach a third-party engine like open-appsec or Coraza.
How do I add a WAF to Kong Gateway?
Three main approaches. First, Kong Enterprise plugins: enable Injection Protection, JSON Threat Protection, XML Threat Protection, and Request Validator, which run in-gateway. Second, a third-party Kong plugin: the open-appsec ML engine ships a dedicated Lua-based Kong plugin. Third, an OWASP CRS engine: run Coraza through a community Kong/OpenResty integration or ModSecurity on the underlying NGINX or as a sidecar. Which you pick depends on whether you have an Enterprise license and whether you need CRS rules.
Does Kong Gateway have a plugin called "WAF"?
No. There is no single Kong plugin named "WAF." Kong's own WAF documentation describes building web application firewall coverage from a combination of plugins, including Injection Protection, JSON and XML Threat Protection, Request Validator, Bot Detection, IP Restriction, and Rate Limiting, rather than shipping a monolithic WAF module. For public Konnect Dedicated Cloud Gateways, Kong does not provide a native WAF; instead it recommends attaching a third-party CDN-level WAF (such as AWS WAF, Azure WAF, Cloudflare, or Fastly) in front of the gateway as a customer-supplied Layer 7 control.
Does Kong's WAF support the OWASP Core Rule Set?
No. Kong's native Injection Protection plugin uses its own predefined and custom regex patterns for SQLi, XSS, SSI, XPath, and Java-exception detection, not the OWASP CRS. To run the CRS (v4) on Kong you attach Coraza through a community Kong/OpenResty integration, or run ModSecurity on the underlying NGINX or as a sidecar. Both execute CRS and SecLang rules directly.
What does the Kong Injection Protection plugin do?
It is an Enterprise plugin (Kong Gateway 3.9+) that does regex matching for common injection patterns. Only SQL injection is checked by default; you enable cross-site scripting, server-side includes, XPath, Java exceptions, and the other predefined types through the injection_types setting, alongside support for custom regexes. It inspects request headers, path and query parameters, and the payload body, depending on configuration, and blocks a match by returning a 400 status while logging the injection type and the matched pattern. See the Injection Protection reference for the full configuration.
Can I use open-appsec, Coraza, or ModSecurity with Kong?
Yes. open-appsec ships a dedicated, open source, Lua-based Kong Gateway plugin (Beta) that adds machine-learning threat detection, installable via LuaRocks, Docker Compose, or a Kong container image. Coraza runs the OWASP CRS through community Kong or OpenResty integrations. ModSecurity runs on the underlying NGINX via its connector or as a sidecar. Wallarm also provides a native Kong integration for API security. Only open-appsec and Kong's own Enterprise plugins are true Kong plugins; the CRS engines are self-managed integrations.
Can I rate limit and block bad traffic in Kong without a WAF?
Yes, up to a point. Kong's Rate Limiting plugin (and the Enterprise Rate Limiting Advanced) throttle request rates per service, route, or consumer; IP Restriction enforces allow/deny CIDR lists; and Bot Detection blocks known bots by User-Agent regex, returning a 403. That covers abuse and access control efficiently in-gateway. What these do not do is inspect request payloads for injection or XSS, which is where a WAF plugin or engine is required.
Kong Enterprise plugins vs an open source WAF engine, which should I pick?
Kong's Enterprise plugins (Injection Protection, JSON/XML Threat Protection, Request Validator) run in-process with no extra hop and are managed with the rest of your Kong config, but they require a commercial license and do not run the OWASP CRS. An open source engine, open-appsec for ML detection or Coraza for CRS rules, is free and gives you either behavioral ML or transparent CRS/SecLang rules you fully control, at the cost of self-managed integration. Choose Enterprise plugins for tight Kong integration and support; choose open-appsec or Coraza when budget, ML detection, or CRS transparency matter most.