Kong Gateway Security Review

We need an Admin API or Kong Manager account for each RBAC role you want tested, from a read-only account through to an admin or super-admin account, plus at least one authenticated Consumer credential for every auth plugin, key-auth, JWT, OAuth2 or OpenID Connect, configured on the routes in scope. If a declarative configuration repository or decK pipeline is in scope, we also need read access to it.

We test the Services, Routes and Consumers you nominate using the accounts and credentials you provide, rather than a copy of your gateway, so we agree exclusions such as production upstream services or destructive rate-limit resets before testing starts. We do not delete Consumers, revoke credentials or change plugin configuration without that agreement in writing.

The plugin, scoping and Consumer model are the same everywhere Kong runs, but the access-control layer differs: self-managed Kong Gateway Enterprise uses its own RBAC and Workspaces, while Konnect replaces that with its own teams and roles and does not run the classic OAuth2 plugin or the cluster rate-limiting policy at all. We confirm during scoping which deployment model you run and test to that boundary.

We never test Kong’s own source code, the underlying host of a Konnect-managed control plane, or a separately hosted upstream application beyond how it trusts Kong’s headers, which is scoped and quoted on its own. We test the Admin API, Kong Manager, plugin configuration, Consumers, credentials and declarative configuration for the estate you nominate.

Self-managed Kong Gateway is software you run yourself, so there is no vendor notification process to follow before testing your own deployment, and a genuine vulnerability in Kong’s own code is reported through Kong’s Responsible Disclosure Program instead. Konnect is Kong’s own hosted control plane, so we confirm Kong’s current customer security-testing terms for it during scoping.

A single Kong Gateway estate, with a limited number of Services, Routes and Consumers, sits in our 3-day single-estate scope, with a report typically landing around 5 working days after kickoff. More Services, a larger Consumer base, or multiple Workspaces or Control Planes moves into a larger scope with more testing days.

No. Testing is black-box against the running Admin API, Kong Manager and proxied routes by default. A grey-box option, where we review your decK declarative configuration files and Vault setup alongside testing, is available if you want faster or deeper coverage of specific findings.

Yes, if Kong Manager is deployed and reachable. If it sits behind a VPN, IP allowlist or network our test team cannot reach without extra setup, tell us during scoping so we can arrange access or agree to exclude it.