How to Set Up a WAF with Kong Gateway

Before enabling anything, be clear about what Kong is and is not. Kong is an API gateway built on OpenResty/NGINX. Open source Kong has no bundled ModSecurity or Coraza engine and does not run the OWASP Core Rule Set. Kong's WAF documentation describes WAF as a composition of plugins rather than a single rule engine. There are three realistic approaches:

• Compose Kong security plugins (this guide): Chain Injection Protection, JSON/XML Threat Protection, Bot Detection, IP Restriction, Rate Limiting, and Request Size Limiting on your Services and Routes. This covers common API threats but is not CRS.
• Front the gateway with a real WAF (managed/cloud): For a public Dedicated Cloud Gateway, put a CDN plus a cloud WAF (for example AWS WAF managed rules on CloudFront) in front and validate origin traffic. Covered in a later step.
• Run a community Coraza plugin (self hosted): Community projects embed the OWASP Coraza engine and CRS v4 into Kong as a plugin server. Not an official Kong plugin; you own the build and support. Covered in a later step.

Also note the tier and version split: Bot Detection, IP Restriction, Rate Limiting, and Request Size Limiting are in open source Kong, while Injection Protection (Kong 3.9+), JSON Threat Protection (Kong 3.8+), XML Threat Protection (Kong 3.1+), Request Validator, and Rate Limiting Advanced are Enterprise / Konnect plugins.

Start with the plugins bundled in open source Kong. This declarative kong.yaml attaches IP Restriction, Request Size Limiting, and Bot Detection globally, plus basic Rate Limiting on a Service:

_format_version: "3.0"

services:
- name: my-api
  url: http://upstream:8080
  routes:
  - name: my-api-route
    paths:
    - /api

plugins:
# Block oversized bodies (returns HTTP 413)
- name: request-size-limiting
  config:
    allowed_payload_size: 10
    size_unit: megabytes
    require_content_length: false

# Block known bad user agents by regex (returns HTTP 403)
- name: bot-detection
  config:
    deny:
    - "(C)|(c)url"
    - "python-requests"

# Deny abusive source ranges (returns HTTP 403)
- name: ip-restriction
  config:
    deny:
    - 203.0.113.0/24
    status: 403
    message: "Access denied"

Then add rate limiting per client. On open source Kong use the Rate Limiting plugin; on Enterprise/Konnect prefer Rate Limiting Advanced for sliding windows and shared counters. For a single node, strategy: local needs no external store. For multiple nodes, use strategy: redis, which requires a config.redis block and works in hybrid, DB-less, and Konnect deployments:

plugins:
- name: rate-limiting-advanced
  service: my-api
  config:
    limit:
    - 100
    window_size:
    - 60
    window_type: sliding
    identifier: ip
    strategy: redis
    sync_rate: 1
    redis:
      host: redis
      port: 6379

The Injection Protection plugin (Enterprise / Konnect, Kong Gateway 3.9+) matches request content against built in regex patterns for injection classes. It is the closest thing Kong ships to signature based WAF detection. Configure which injection types and which request locations to inspect, and start in log_only mode:

plugins:
- name: injection-protection
  service: my-api
  config:
    injection_types:
    - sql
    - js
    locations:
    - path_and_query
    - body
    - headers
    enforcement_mode: log_only
    error_status_code: 400
    error_message: "Bad Request"

The configuration reference lists the full set of injection_types (sql, sql_low_sensitivity, js, java_exception, ssi, xpath_abbreviated, xpath_extended) and locations (body, headers, path, path_and_query, query). You can also add custom_injections with a name and regex for patterns specific to your app. Note the plugin's defaults: enforcement_mode defaults to block (not log_only) and locations defaults to [path_and_query], so the explicit settings above override both. A partial copy that omits them will block from the first request and never scan request bodies.

APIs are attacked through oversized and deeply nested payloads as well as injection strings. The JSON Threat Protection plugin (Kong 3.8+; POST/PUT/PATCH body validation requires Kong 3.10+) enforces structural limits on JSON bodies:

plugins:
- name: json-threat-protection
  service: my-api
  config:
    max_body_size: 1000000
    max_container_depth: 20
    max_object_entry_count: 100
    max_object_entry_name_length: 100
    max_array_element_count: 1000
    max_string_value_length: 10000
    enforce_mode: block
    error_status_code: 400

If you accept XML, add the XML Threat Protection plugin (Kong 3.1+), which similarly caps element depth, attribute counts, and value sizes to defend against XML bomb and entity expansion attacks. Note an important difference between the two: JSON Threat Protection supports a log only phase through enforce_mode: log_only, so set that first if you are unsure of your legitimate payload shapes, then switch to enforce_mode: block. XML Threat Protection has no enforce mode and no log only mode; it always blocks on a limit violation, so validate its max_* limits carefully against real XML payloads before you enable it.

The strongest API layer defense Kong offers is positive validation: rejecting anything that does not match an expected schema. The Request Validator plugin (Enterprise / Konnect) validates request bodies and parameters against a JSON Schema (Draft 4, version: draft4) or Kong's native schema (version: kong) that you supply directly per Route (optionally generated from an OpenAPI spec with deck file openapi2kong, a separate decK tool, not a feature of the plugin itself):

plugins:
- name: request-validator
  route: my-api-route
  config:
    version: draft4
    body_schema: |
      {
        "type": "object",
        "required": ["id"],
        "properties": {
          "id": { "type": "integer", "minimum": 1 }
        },
        "additionalProperties": false
      }
    allowed_content_types:
    - application/json
    verbose_response: false

Because it allowlists structure rather than blocklisting known attacks, a request validator catches whole classes of injection and parameter tampering that signature matching misses, at the cost of maintaining a schema per Route.

None of the plugins above run the OWASP Core Rule Set. If your compliance or threat model requires CRS, choose one of two honest paths:

Managed / cloud path (Dedicated Cloud Gateways): A public Dedicated Cloud Gateway exposes a DNS hostname, so you front it with a CDN that can attach a cloud WAF. Per Kong's public network security guide, put AWS WAF managed rules on a CloudFront distribution, then lock the origin so traffic cannot bypass the CDN. CloudFront injects a shared secret header and Kong requires it:

# Reject any request that did not come through the CDN
plugins:
- name: request-termination
  config:
    status_code: 403
    message: "Direct origin access denied"
# ...enabled via a Route that matches when the
# X-Origin-Verify header is absent or wrong.
# Also allowlist the CDN egress ranges:
- name: ip-restriction
  config:
    allow:
    - 130.176.0.0/16   # example CDN egress range

Kong recommends storing the shared header value in a Vault and rotating it periodically.

Self hosted path (community Coraza plugin): Community projects embed the OWASP Coraza engine and CRS v4 into Kong as a Go plugin server, compatible with hybrid, traditional, and DB-less topologies. You build a custom Kong image and enable the plugin server via environment variables, for example:

KONG_PLUGINS=bundled,kong-waf
KONG_PLUGINSERVER_NAMES=kong-waf
KONG_PLUGINSERVER_KONG_WAF_QUERY_CMD="/usr/local/bin/kong-waf -dump"

The plugin is then configured dynamically through the Admin API with SecLang/CRS directives.

Push the declarative config to your control plane with decK, which validates and syncs the full state:

# Validate the file first
deck gateway validate kong.yaml

# Sync it to Kong (Admin API or Konnect control plane)
deck gateway sync kong.yaml

You can also enable each plugin imperatively through the Admin API or the Konnect UI. Confirm the plugins are active on your Service or Route:

curl -s http://localhost:8001/plugins | \
  grep -o '"name":"[^"]*"'

With Injection Protection switched to enforcement_mode: block, send known attack payloads and confirm each plugin rejects them:

# SQL injection in the query string (Injection Protection, 400)
curl -i 'http://localhost:8000/api?id=1%20OR%201=1'

# SQL injection in a JSON body (Injection Protection, 400)
curl -i -X POST http://localhost:8000/api \
  -H 'Content-Type: application/json' \
  -d '{"id":"1 OR 1=1"}'

# Denied bot user agent (Bot Detection, 403)
curl -i -A 'python-requests/2.31' http://localhost:8000/api

# Oversized body (Request Size Limiting, 413)
head -c 20000000 /dev/zero | \
  curl -i -X POST --data-binary @- http://localhost:8000/api

# Flood past the limit (Rate Limiting, 429)
for i in $(seq 1 200); do \
  curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8000/api; done

# A normal request (should return 200)
curl -i 'http://localhost:8000/api?id=42'

Run the tunable inspection plugins in log only mode for one to two weeks and review the Kong logs for legitimate requests that would have been rejected. Injection Protection emits a structured log line naming the threat type, action, and location for every match, which is where you identify false positives.

Tune by narrowing the locations Injection Protection inspects, loosening a specific max_* limit in the threat protection plugins, or refining the body_schema in Request Validator so real traffic validates. Once the logs are clean, flip enforcement_mode (Injection Protection) and enforce_mode (JSON Threat Protection) to block and re-sync with decK. XML Threat Protection has no log only mode and already blocks on any violation, so there is nothing to flip there; just confirm its max_* limits match your real XML traffic before it goes live.

# After tuning, enforce
deck gateway sync kong.yaml
# Watch for new false positives in the logs
kubectl logs -f deploy/kong-gateway   # or docker/systemd logs