Plataforma Actualizado julio 2026 por Thijs de Zoete

Mejor WAF para Kong Gateway

Añade protección de firewall de aplicaciones web a Kong Gateway. Compara los propios plugins de seguridad de Kong Enterprise (Injection Protection, JSON/XML Threat Protection, Request Validator) frente a motores de terceros que se integran con Kong, incluidos open-appsec, Coraza (OWASP CRS) y ModSecurity.

Kong Gateway es uno de los API gateways de código abierto más desplegados, construido sobre OpenResty y NGINX y situado por delante de APIs y microservicios en grandes empresas. Como termina y enruta el tráfico del cliente antes de que llegue a tus servicios, y ya se encarga de la autenticación, la limitación de tasa y la transformación de peticiones, Kong es un lugar natural para aplicar política de seguridad en la capa de aplicación.

Conviene dejar clara una cosa de entrada: Kong no tiene un único plugin que se llame literalmente "WAF". La propia guía de WAF de Kong describe cómo ensamblar la cobertura de firewall de aplicaciones web a partir de un conjunto de plugins de seguridad, en lugar de un módulo WAF monolítico. Varios de los más relevantes, entre ellos Injection Protection, JSON Threat Protection y XML Threat Protection, son exclusivos de Enterprise; otros, como Bot Detection, IP Restriction y Rate Limiting, vienen con la edición de código abierto de Kong. Ninguno de los plugins nativos de Kong ejecuta el OWASP Core Rule Set; para tener cobertura del CRS conectas un motor de terceros a través de la arquitectura de plugins de Kong.

Esta guía compara las vías realistas para poner un WAF en Kong: los propios plugins de seguridad de Kong Enterprise, el motor de machine learning open-appsec (que ofrece un plugin dedicado para Kong), Coraza ejecutando el OWASP CRS mediante integraciones comunitarias de Kong/OpenResty, y ModSecurity a través del NGINX subyacente o de un sidecar. También cubre lo que Kong puede y no puede hacer de forma nativa para que decidas dónde encaja el WAF en tu stack de APIs.

Mejores Proveedores WAF para Kong Gateway

3

Coraza Web Application Firewall

OWASP CRS de código abierto

Coraza es la vía de código abierto para ejecutar el OWASP Core Rule Set por delante de Kong. Es un motor moderno, compatible con ModSecurity, escrito en Go sin dependencias de C, y ejecuta el CRS v4 (SQLi, XSS, inyección de código, detección de escáneres y más) además de cualquier regla SecLang que aportes. Ten en cuenta que no hay un plugin oficial para Kong: Coraza llega a Kong a través de plugins Lua comunitarios o de una capa proxy-wasm/sidecar sobre OpenResty, así que valida la integración concreta y fija las versiones antes de producción. La mejor opción cuando quieres reglas CRS transparentes y estándar del sector que controlas por completo.

Beneficios Clave:

  • Ejecuta el OWASP CRS v4 y reglas SecLang de ModSecurity
  • Motor en Go puro, sin dependencias de C, fácil de contenerizar
  • Gratuito y de código abierto (proyecto OWASP, Apache 2.0)
  • Se conecta mediante integraciones comunitarias de Kong/OpenResty
Calificación: 4,2/5
Precios: Gratuito y de código abierto (Apache 2.0)
Plan Gratuito
Leer Reseña Completa Visitar Sitio Web
4

ModSecurity Open Source WAF

Reglas estándar del sector

ModSecurity es el motor WAF veterano y probado en batalla, y el origen del lenguaje de reglas SecLang y del ecosistema del OWASP CRS. No hay un plugin oficial para Kong; como Kong está construido sobre NGINX/OpenResty, los equipos suelen ejecutar libmodsecurity a través del conector ModSecurity para NGINX en el proxy subyacente, o desplegar ModSecurity como sidecar por delante de Kong. Es una opción sólida si tu equipo ya mantiene reglas SecLang, con la contrapartida de que la integración específica con Kong es autogestionada en lugar de un plugin soportado y listo para usar.

Beneficios Clave:

  • Ecosistema maduro de reglas SecLang y OWASP CRS
  • Se ejecuta sobre el NGINX/OpenResty subyacente o como sidecar
  • Gratuito y de código abierto, sin coste de licencia
  • Familiar para equipos que migran reglas ModSecurity existentes
Calificación: 4,0/5
Precios: Gratuito (Código Abierto)
Plan Gratuito
Leer Reseña Completa Visitar Sitio Web

Qué Buscar en un WAF para Kong Gateway

A la hora de elegir cómo añadir un WAF a Kong Gateway, sopesa estos factores:

  • Plugins nativos frente a un motor de terceros - Los propios plugins tipo WAF de Kong se ejecutan en proceso y se integran de forma limpia con el enrutamiento y la autenticación, pero los más potentes (Injection Protection, JSON/XML Threat Protection, Request Validator) son exclusivos de Enterprise. Motores de terceros como open-appsec o Coraza se conectan a través de la arquitectura de plugins y pueden ser gratuitos y de código abierto.
  • Soporte del OWASP Core Rule Set - Los plugins nativos de Kong no ejecutan el OWASP CRS. Si necesitas cobertura del CRS, cuenta con Coraza o ModSecurity, que ejecutan reglas CRS/SecLang directamente. Confirma la versión del CRS (la v4 es la actual) y cómo se entregan las actualizaciones de reglas.
  • Licenciamiento Enterprise - El plugin Injection Protection requiere Kong Gateway 3.9+ y una licencia Enterprise; JSON Threat Protection requiere 3.8+ y XML Threat Protection 3.1+, ambas Enterprise. Confirma qué nivel necesitan tus plugins antes de construir un diseño en torno a ellos.
  • Firmas/regex frente a machine learning - Injection Protection y Bot Detection se basan en regex; open-appsec se basa en ML; Coraza/ModSecurity son motores de reglas CRS. Cada uno tiene características distintas de ajuste y falsos positivos, así que adapta el motor a tu modelo de amenazas.
  • Limitación de tasa y control de acceso nativos - Kong ya hace mucho antes de cualquier WAF: Rate Limiting (y el Rate Limiting Advanced de Enterprise), IP Restriction y Bot Detection gestionan el abuso y el control de acceso de forma eficiente en el gateway. Decide qué resolver con esos frente a lo que realmente necesita inspección de contenido.
  • IP real del cliente - Si Kong se sitúa detrás de un CDN o un balanceador de carga, configura las IP de confianza y el manejo de X-Forwarded-For para que el WAF, la restricción de IP y los límites de tasa vean la dirección real del cliente, no la del proxy aguas arriba.

Consideraciones para Kong Gateway

Consideraciones específicas de Kong al desplegar un WAF:

  • Kong de código abierto no tiene plugin WAF de capa de aplicación - El gateway gratuito incluye Bot Detection, IP Restriction, Rate Limiting y Request Size Limiting, pero los plugins que inspeccionan el contenido (Injection Protection, JSON/XML Threat Protection, Request Validator) son exclusivos de Enterprise. No asumas que Kong de código abierto inspecciona el cuerpo de las peticiones en busca de SQLi o XSS; no lo hace sin un motor añadido.
  • El WAF es una cadena de plugins, no un solo módulo - El enfoque de Kong es componer varios plugins de seguridad en la cadena de ejecución. Planifica el orden (por ejemplo IP Restriction y Bot Detection al principio, Injection Protection y validadores antes de hacer proxy) para que los rechazos baratos ocurran antes que la inspección costosa.
  • Sin OWASP CRS de forma nativa - El Injection Protection de Kong usa sus propios patrones regex predefinidos y personalizados, no el OWASP CRS. Para cobertura CRS/SecLang conectas Coraza (integración comunitaria de Kong/OpenResty) o ejecutas ModSecurity sobre el NGINX subyacente o como sidecar.
  • Construido sobre NGINX/OpenResty - Como Kong se ejecuta sobre OpenResty, puedes añadir plugins WAF basados en Lua como el complemento de open-appsec, o recurrir al conector ModSecurity para NGINX en la capa de proxy. Esta flexibilidad es real, pero las vías no nativas son autogestionadas.
  • Dedicated Cloud Gateways de Konnect - Kong no proporciona un WAF nativo para los Dedicated Cloud Gateways. Como los Dedicated Cloud Gateways públicos exponen un nombre de host DNS en lugar de IP estáticas, Kong recomienda traer tu propio WAF conectando un CDN que soporte orígenes basados en DNS y pueda transportar la política de WAF (la guía de red pública de Kong menciona Amazon CloudFront con AWS WAF, Azure Front Door con Azure WAF, Cloudflare y Fastly con Next-Gen WAF) por delante del gateway como defensa de primera línea en la capa 7. Cuando el CDN publica rangos de IP de salida estáticos, combínalo con el plugin IP Restriction para poner esas IP en lista blanca. Se trata de un control de terceros aportado por el cliente, no de un WAF proporcionado por Kong.
  • Forma de despliegue - Los mismos plugins se ejecutan en Linux/Docker autoalojado, en Kubernetes mediante el Kong Ingress Controller (gestionado a través de CRDs), en modo híbrido con un plano de control en la nube y planos de datos autogestionados, y en Konnect. La política del WAF viaja con tu configuración declarativa de Kong.

Preguntas Frecuentes

¿Incluye Kong Gateway de código abierto un WAF?

No un WAF completo de la capa de aplicación. Kong de código abierto incluye plugins de seguridad como Bot Detection, IP Restriction, Rate Limiting y Request Size Limiting, que gestionan bots, control de acceso y abuso. Los plugins que inspeccionan el contenido y detectan inyección SQL y XSS, como Injection Protection y JSON/XML Threat Protection, son exclusivos de Enterprise. Para inspección de contenido en código abierto conectas un motor de terceros como open-appsec o Coraza.

¿Cómo añado un WAF a Kong Gateway?

Tres enfoques principales. Primero, plugins de Kong Enterprise: habilita Injection Protection, JSON Threat Protection, XML Threat Protection y Request Validator, que se ejecutan en el gateway. Segundo, un plugin de Kong de terceros: el motor de ML open-appsec ofrece un plugin dedicado para Kong basado en Lua. Tercero, un motor de OWASP CRS: ejecuta Coraza mediante una integración comunitaria de Kong/OpenResty, o ModSecurity sobre el NGINX subyacente o como sidecar. Cuál elijas depende de si tienes una licencia Enterprise y de si necesitas reglas CRS.

¿Tiene Kong Gateway un plugin llamado "WAF"?

No. No hay un único plugin de Kong llamado "WAF". La propia documentación de WAF de Kong describe cómo construir la cobertura de firewall de aplicaciones web a partir de una combinación de plugins, entre ellos Injection Protection, JSON y XML Threat Protection, Request Validator, Bot Detection, IP Restriction y Rate Limiting, en lugar de ofrecer un módulo WAF monolítico. Para los Dedicated Cloud Gateways públicos de Konnect, Kong no proporciona un WAF nativo; en su lugar recomienda conectar un WAF de terceros a nivel de CDN (como AWS WAF, Azure WAF, Cloudflare o Fastly) por delante del gateway como control de capa 7 aportado por el cliente.

¿Soporta el WAF de Kong el OWASP Core Rule Set?

No. El plugin nativo Injection Protection de Kong usa sus propios patrones regex predefinidos y personalizados para detectar SQLi, XSS, SSI, XPath y excepciones de Java, no el OWASP CRS. Para ejecutar el CRS (v4) en Kong conectas Coraza mediante una integración comunitaria de Kong/OpenResty, o ejecutas ModSecurity sobre el NGINX subyacente o como sidecar. Ambos ejecutan reglas CRS y SecLang directamente.

¿Qué hace el plugin Injection Protection de Kong?

Es un plugin de Enterprise (Kong Gateway 3.9+) que hace coincidencia con regex de patrones de inyección comunes. Solo la inyección SQL se comprueba de fábrica; el cross-site scripting, los server-side includes, XPath, las excepciones de Java y los demás tipos predefinidos se habilitan mediante el ajuste injection_types, junto con soporte para regex personalizadas. Inspecciona las cabeceras de la petición, los parámetros de ruta y query, y el cuerpo del payload, según la configuración, y bloquea una coincidencia devolviendo un estado 400 mientras registra el tipo de inyección y el patrón coincidente. Consulta la referencia de Injection Protection para la configuración completa.

¿Puedo usar open-appsec, Coraza o ModSecurity con Kong?

Sí. open-appsec ofrece un plugin dedicado para Kong Gateway, de código abierto y basado en Lua (Beta), que añade detección de amenazas por machine learning, instalable vía LuaRocks, Docker Compose o una imagen de contenedor de Kong. Coraza ejecuta el OWASP CRS mediante integraciones comunitarias de Kong u OpenResty. ModSecurity se ejecuta sobre el NGINX subyacente a través de su conector o como sidecar. Wallarm también proporciona una integración nativa con Kong para seguridad de APIs. Solo open-appsec y los propios plugins de Kong Enterprise son verdaderos plugins de Kong; los motores de CRS son integraciones autogestionadas.

¿Puedo limitar la tasa y bloquear tráfico malicioso en Kong sin un WAF?

Sí, hasta cierto punto. El plugin Rate Limiting de Kong (y el Rate Limiting Advanced de Enterprise) regula las tasas de peticiones por servicio, ruta o consumidor; IP Restriction impone listas CIDR de permitir/denegar; y Bot Detection bloquea bots conocidos mediante regex de User-Agent, devolviendo un 403. Eso cubre el abuso y el control de acceso de forma eficiente en el gateway. Lo que no hacen es inspeccionar el contenido de las peticiones en busca de inyección o XSS, que es donde se necesita un plugin o motor WAF.

Plugins de Kong Enterprise frente a un motor WAF de código abierto, ¿cuál elijo?

Los plugins de Kong Enterprise (Injection Protection, JSON/XML Threat Protection, Request Validator) se ejecutan en proceso sin salto adicional y se gestionan junto al resto de tu configuración de Kong, pero requieren una licencia comercial y no ejecutan el OWASP CRS. Un motor de código abierto, open-appsec para detección por ML o Coraza para reglas CRS, es gratuito y te da o bien ML de comportamiento o bien reglas CRS/SecLang transparentes que controlas por completo, a costa de una integración autogestionada. Elige los plugins de Enterprise por una integración estrecha con Kong y soporte; elige open-appsec o Coraza cuando el presupuesto, la detección por ML o la transparencia del CRS son lo más importante.