Open source API management for the OWASP API Security Top 10: what the gateway can and cannot cover
Many organizations reach the point where APIs have grown across teams, clouds and vendors without a single entry point, and the security team is asked to show how the OWASP API Security Top 10 2023 risks are handled. A self-hosted gateway such as Apache APISIX or Kong Gateway can enforce authentication, rate limits, and schema and routing controls at the edge, but object-level authorization and business logic remain the application's responsibility. Treat the gateway as a strong first control layer, not as a substitute for secure code.
The OWASP API Security Top 10 2023 lists ten risks, identified as API1 through API10, covering broken authorization and authentication, resource consumption, sensitive business flows, server-side request forgery, misconfiguration, inventory management and unsafe consumption of third-party APIs. Map each ID to a named owner and to a concrete control: a gateway plugin, a policy in the identity provider, a check in the application or a test in the release pipeline. The inventory risk (API9) is where the gateway helps most, because every route it serves becomes a record you can list, review and retire. Confirm with your team whether shadow APIs reach services without passing through the gateway, since an inventory only covers traffic that actually flows through it.
Expect gaps in the object-level and property-level risks (API1, API3 and API5). A gateway can check that a token is valid and that a caller holds a scope, but it does not know that customer 1042 may not read invoice 88 belonging to customer 2011. Plan for those checks in the service code or in an authorization service, and use the gateway's access logs to verify them after release. For the openid-connect plugin, confirm with your identity provider team which flows and token claims you will use, because the policy you configure at the gateway is only as strong as the claims it receives. The sibling pages on financial services and healthcare cover sector-specific detail.
How each OWASP API risk maps to gateway controls and application work
This table compares each OWASP API Security Top 10 2023 risk with what a self-hosted APISIX or Kong gateway can enforce and what must stay in the application code. Read the middle column for gateway controls and the last column for the configuration to confirm before promising coverage. The main takeaway is that a gateway narrows several risks but cannot fix authorization logic inside the service.
| Risk | Gateway can enforce | Stays in the application | Configuration to confirm |
|---|---|---|---|
| API1 Broken object level authorization | Coarse route checks and token scope gates that block obviously unauthorized paths | Checking that a caller owns or may access each specific object ID | Confirm the upstream enforces ownership checks on every object route |
| API2 Broken authentication | Token validation through an OIDC plugin tied to Keycloak, key checks and mTLS on sensitive routes | Session handling, password rules and account recovery logic | APISIX openid-connect and Kong OpenID Connect differ in tier, so confirm the plugin and licence first |
| API3 Broken object property level authorization | Response filtering and request body schema checks on known fields | Deciding which properties each role may read or write | Confirm response transformation plugins exist in your edition and version |
| API4 Unrestricted resource consumption | Rate limiting, request size limits, concurrency and timeout controls per consumer or route | Query cost limits, pagination caps and expensive operation budgets | Set limits per consumer key and test them under load before go-live |
| API5 Broken function level authorization | Route-level role or scope checks for admin and privileged paths | Enforcing role logic inside each function and checking inherited permissions | Map every admin route to a required scope in the gateway configuration |
| API6 Unrestricted access to sensitive business flows | Rate limits and bot or abuse controls on flows such as signup, checkout or coupon endpoints | Business rules such as purchase limits and fraud decisions | Identify the flows with the business owner and confirm which controls apply to each |
| API7 Server side request forgery | Restrict outbound destinations on the gateway and avoid proxying user-supplied URLs | Validating URLs the service fetches and blocking internal address resolution | Confirm network egress rules at the host or cloud level, not only in the gateway |
| API8 Security misconfiguration | Disable unneeded plugins, enforce TLS versions, hide admin endpoints and keep the Admin API off public networks | Secure defaults in frameworks, error handling and CORS settings in services | Review the APISIX port 9180 or Kong Admin API 8001 exposure and TLS settings in the deployment |
| API9 Improper inventory management | Central route and upstream inventory in version-controlled configuration, showing exposed and deprecated paths | Documenting internal endpoints and retiring unused versions | Reconcile gateway routes against service catalogs and code repositories on a schedule |
| API10 Unsafe consumption of APIs | Limits and timeouts on calls to third-party upstreams, plus allowlists of approved partner endpoints | Validating and sanitizing data received from third-party APIs | Confirm which outbound calls pass through the gateway and which bypass it |
Why object-level authorization stays in the application
A gateway sees a token and a route, but not which record a user owns. When a request arrives at /orders/8841, APISIX or Kong can confirm the token is valid, the scopes are present and the caller is within its rate limit. It cannot know whether order 8841 belongs to the caller. That decision depends on business data inside the service, so BOLA (API1 in the OWASP API Security Top 10 2023), property-level exposure (API3) and function-level checks (API5) must be enforced in the application or in a policy engine that the application calls. A gateway policy that only checks the route is a common source of false confidence here.
Ask developers to implement an explicit ownership or relationship check on every endpoint that takes an object identifier, and to deny by default when the check cannot be evaluated. For API3, ask for response serializers with allowlisted fields per role, so that internal attributes such as account flags are never returned by accident. For API5, ask for a documented matrix of which roles may call which administrative functions and a test that calls each one with a lower-privileged token. Illustrative example: a customer token with a valid scope requests another customer's invoice ID. The gateway passes the request, and the service must return a 403 or 404 on its own. Your test plan should include that exact case for every object type.
The gateway still helps. Configure it to validate the token with the identity provider (Keycloak is one option, and the APISIX openid-connect plugin supports token introspection) and to forward verified identity claims, such as the subject and roles, to the upstream service in headers that clients cannot spoof. Confirm in your own environment which claims your identity provider issues and which header names your services will trust, and make sure the gateway strips any incoming copies of those headers. The service then makes the object-level decision using the verified subject, which keeps authentication at the edge and authorization close to the data.
Which open-source gateway fits this OWASP control set
The OWASP controls split between what a gateway can enforce at the edge and what must stay in the application. The options below cover the two gateways most often self-hosted for this job and the identity provider that usually sits behind them, plus one commercial option to verify before you rely on it.
Apache APISIX as the enforcement point
Apache APISIX is licensed under Apache-2.0 and is a top-level Apache Software Foundation project. Version 3.19.0 was released on September 28, 2026. Its documentation describes more than 100 built-in plugins covering authentication, traffic control and observability, which map to API2, API4 and API9 controls. It runs in traditional mode (data and control plane together), decoupled mode (separate planes sharing one etcd cluster) or standalone mode (configuration from a YAML or JSON file). Check whether your team can operate etcd, and whether file-driven standalone mode fits your change-control process.
Kong Gateway open source edition
Kong Gateway open source is licensed under Apache-2.0, with version 3.9.4 released on October 12, 2026. Its self-managed topologies are traditional, DB-less and hybrid. DB-less mode suits version-controlled declarative configuration, while hybrid mode separates control and data planes. The OpenID Connect plugin is an Enterprise tier feature, so an open source deployment will need a different path for OIDC token validation. Confirm which authentication, rate limiting and schema validation plugins your version includes before you map controls to them.
Keycloak as the identity provider
Keycloak is an Apache 2.0 licensed identity and access management server that supports OpenID Connect, OAuth 2.0 and SAML 2.0. It covers the authentication side of API2 and provides the token issuance the gateway validates, while object-level and function-level checks remain in the service. Version 26.8.1 was released on October 13, 2026. Plan its database (PostgreSQL 14 to 18 is among the supported options) and high availability design early, because both supported multi-site designs need a synchronously replicated database.
API7 Enterprise as a commercial option
API7 Enterprise is a commercial distribution associated with APISIX. Do not assume its feature set, support terms or licensing match the open source project. Ask the vendor to confirm in writing which OWASP-relevant controls it adds, how it is licensed and supported, and whether its management layer runs inside your own infrastructure. Compare it against the open source gateway on the same control list so the choice rests on documented capability rather than marketing claims.
How a gateway gives you the API inventory OWASP asks for
The sequence turns scattered API endpoints into a single, exported and version-controlled inventory that matches what the gateway actually routes. It shows which APIs are documented, which are undocumented, and which must be blocked or retired.
Route all north-south traffic through the gateway
The platform team and network owners point external and partner-facing DNS records, load balancer targets and ingress rules at the gateway data plane, so client traffic reaches upstream services only through it. Owners of each public hostname confirm the change in writing. The step is done when access logs show traffic for each hostname passing through the gateway and no new direct routes are opened to backend services.
Export routes, upstreams and plugin configuration
The gateway engineers pull the current configuration from the Admin API, which in traditional mode listens on port 9180, or from the declarative files in standalone mode. They save routes, upstreams, consumers, services and attached plugins as a dated snapshot. The output is a complete configuration file set that lists every path, method, upstream target and authentication plugin the gateway enforces today.
Reconcile the snapshot against the service catalog
API owners and architects compare the exported routes with the service catalog, the OpenAPI specifications and the CMDB entries. Each route is matched to an owner, a business purpose, a data classification and a documented version. Gaps are logged in both directions: routes with no owner, and catalog entries with no route. The check is complete when every live route has a named owner and an accepted specification, or a recorded exception.
Find shadow APIs that bypass the gateway
The team looks for APIs reachable without passing through the gateway, such as legacy hostnames, internal services exposed through old load balancers, cloud function URLs and vendor integrations that call backends directly. Network flow logs, DNS records, certificate transparency results and cloud inventory are the usual sources. Confirm with the network and cloud teams whether any such path exists, because the gateway inventory is only complete for traffic it actually sees.
Decommission or block undocumented routes
For each route without an owner or approved specification, the team either assigns an owner and documents it, or removes it from the gateway and disables the upstream. In standalone mode, the change is made in the YAML or JSON file, which APISIX checks every second and hot-reloads without a restart. The step closes when the blocked routes return a denial in testing and the change is recorded in the change log.
Store gateway configuration in Git
The reconciled configuration is committed to a version-controlled repository, with reviews required before merge and deployments promoted from Git rather than edited on live nodes. Secrets stay in a separate secrets store, and only references appear in the files. The output is a repository where every route, plugin change and removal has an author, a reviewer and a timestamp, which gives the security team an auditable history of the API estate.
Schedule recurring inventory comparisons
The team sets a recurring job that exports the live configuration, diffs it against the Git repository and the service catalog, and raises an alert on any drift or new route. The owner of the job and the review frequency are agreed in the engagement scope. Confirm with the partner whether the comparison runs in your own environment and where its reports are stored, so the inventory remains current after the initial cleanup.
Evidence assessors ask for and which component produces it
This table maps the evidence an assessor typically asks for during a review of API security controls to the component that produces it. Read each row as a question: what does the assessor want to see, and which system holds the answer. DeployOpen prepares this evidence for your assessment, but independent auditors and certification bodies issue any assessment or certification.
| Evidence item | Producing component | What to confirm before the assessment |
|---|---|---|
| API inventory export | Gateway route and upstream configuration, reconciled with the API catalog | Confirm that every route, including those created outside the gateway, appears in the export and that owners are recorded |
| Route and plugin configuration in Git with change history | Declarative gateway config (APISIX standalone YAML or Kong declarative config) stored in version control | Confirm who can approve merges, and that production matches the committed state |
| Authentication policy and token settings | Keycloak realm, client and token lifetime settings, enforced at the gateway through OpenID Connect plugins | Confirm the Keycloak realm export and gateway plugin settings match the documented policy, and that Kong's OpenID Connect plugin is licensed if Kong is chosen |
| Rate limit configuration and test results | Gateway traffic control plugins, with load test output from the test environment | Confirm limits are set per consumer and per route, and that test reports show the limit triggering as designed |
| Schema validation and request size rules | Gateway request validation plugins and their configuration files | Confirm which endpoints have validation enabled and that exceptions are documented with a reason |
| Gateway access logs and metrics | Gateway access logging and metrics exporters, forwarded to your log platform | Confirm log retention meets your policy and any regulatory minimum, and that logs record the authenticated consumer |
| Keycloak administrative and login event records | Keycloak event logging and metrics endpoints | Confirm event storage, retention and who can read administrative events |
| Penetration test or OWASP-aligned test reports | Independent security testing against the API, with findings tracked to remediation | Confirm the scope covers object-level and function-level authorization, which gateways cannot enforce alone, and that retests are recorded |
What gateway tooling alone does not satisfy
A self-hosted gateway enforces authentication, rate limits and schema checks at the edge, but several OWASP API Security Top 10 2023 risks are decided inside services, in outbound calls, in network policy and in the identity platform's own upgrade path. The cards below cover the controls that must be designed, tested and governed alongside the gateway rather than assumed from it.
Object-level authorization stays in code
API1 Broken Object Level Authorization asks whether a caller who is authenticated may access this specific record, such as another customer's invoice identified by a changed ID. A gateway can validate the token and its scopes, but it does not know who owns each object. Each service must check ownership on every read and write. Ask your team to test BOLA and BOPLA (API3, property-level authorization) with two test accounts per tenant in the continuous test suite, not only in a one-time review.
Outbound validation for third-party APIs
API10 Unsafe Consumption of APIs covers the data your services accept from partners, SaaS providers and internal APIs they call. The gateway typically inspects inbound client traffic, so responses from upstream dependencies can reach business logic unchecked. Services should validate schema, types, size and status of every third-party response and treat redirects and pagination links as untrusted input. Confirm which team owns this validation for each integration.
SSRF needs network policy beyond the gateway
API7 Server Side Request Forgery occurs when an API fetches a URL supplied by a caller, which can reach internal metadata services or private networks. A gateway route can restrict which upstreams it forwards to, but any service that makes its own outbound requests needs its own controls. Pair an allowlist of destination hosts with network egress policy in the cluster or cloud account, and test URL parameters on every endpoint that accepts them.
Business flow abuse requires domain logic
API6 Unrestricted Access to Sensitive Business Flows describes automated misuse of legitimate functions, such as mass coupon redemption, account creation or ticket hoarding. Each request looks valid to a gateway, so rate limits per client help but do not capture business intent. Model the sensitive flows in the application and set limits on the business action itself, such as one redemption per account per period, then confirm with product owners which flows qualify.
Keycloak upgrades need governed approval
If Keycloak issues the tokens your gateway validates, its upgrade path becomes an API security dependency. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, and the project plans four minor releases a year. Set a written change process with staging validation of token flows before each approved update, and check the upgrading guide for schema migration choices on large deployments.
Ongoing testing of the API surface
The OWASP risks change as APIs change, and gateway configuration, routes and plugins drift over time. A one-time assessment shows the state on the day it was run. Plan recurring security testing of the API surface, including routes exposed through the gateway, with findings tracked against each OWASP category. Ask a partner to explain how the test scope is refreshed when new routes are published and who signs off on exceptions.
What do buyers ask before an OWASP API gateway project?
How much effort does a self-hosted APISIX or Kong rollout take?
Effort depends on the number of APIs, the deployment mode, the identity integration and how many custom plugins are needed, so no single figure applies. The main choices are whether to run APISIX in traditional, decoupled or standalone mode, or Kong in traditional, DB-less or hybrid topology, because each changes the control plane, the database or etcd footprint and the high availability design. Ask any partner for a written scope that lists the APIs in scope, the identity provider, the plugins to configure, the test plan and the handover documentation. Fixed-scope work is agreed in writing before it starts, and the quote follows from that scope.
Can our in-house team run the gateway without a partner?
A capable platform or security team can run a gateway, but the work is more than installing software. The team needs skills in NGINX-based routing, the chosen configuration model (Admin API, YAML files or a control plane), identity protocols such as OpenID Connect, and the testing needed to confirm each OWASP API risk is handled. Check whether your staff have time for launch and for ongoing upkeep, and whether someone owns the gateway after go-live. A partner can cover some or all of these pieces under a fixed-scope engagement or a retainer.
What recurs after the gateway goes live?
Recurring work includes gateway version upgrades, identity server upgrades, plugin and configuration maintenance, certificate rotation, monitoring and periodic security testing. For Keycloak, the project plans four minor releases a year, and its Operator documentation recommends manual approval mode for operator updates to avoid unintended upgrades. Kong Gateway 3.9 reaches end of sunset support on December 12, 2026, so Kong users on that line need a planned move. Ask whether a support retainer covers upgrades, testing and documentation, and who approves each change.
Does the open-source gateway include the OIDC plugin we need?
It depends on the gateway. Apache APISIX ships an openid-connect plugin under Apache-2.0 that works with identity providers such as Keycloak, Microsoft Entra ID and Okta and supports authorization code, client credentials, token introspection and PKCE flows. Kong's OpenID Connect plugin is marked as an Enterprise tier plugin, so it is not part of the open source gateway. Confirm each required flow, token type and claim mapping against the current plugin documentation before you commit to a design.
How should OWASP API testing be scoped for the gateway?
Scope testing to the risks each layer actually owns. The gateway can be tested for authentication enforcement, rate limits, schema validation, exposed admin interfaces and routing errors, while object-level authorization, object property exposure and business flow abuse need tests against the application itself. Include an inventory check so that undocumented routes are found and brought under policy. Ask the testing provider to map findings to the OWASP API Security Top 10 2023 entries and to state which tests run against the gateway and which run against the services behind it.
Does DeployOpen's work count as a compliance certification?
No. DeployOpen plans, implements, hardens, documents and tests the gateway and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask any partner which evidence they will produce, such as configuration records, test results and access logs, and confirm with your assessor which artifacts they will accept.
What should we ask a partner before signing a gateway contract?
Ask for a written scope that names the gateway product, the deployment mode, the identity integration, the APIs in scope and the testing included. Request the list of deliverables, the handover documentation, the upgrade process and the acceptance criteria. Confirm that all infrastructure stays in your cloud accounts or data centers, and ask who holds administrative credentials at the end of the engagement. Ask how the quote changes if the API count, plugin count or identity requirements change during delivery.
How DeployOpen scopes and delivers an OWASP-aligned gateway
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source gateways inside your own cloud accounts, data centers or air-gapped networks. For OWASP API Security Top 10 coverage, we start from your API inventory and map each risk to what the gateway enforces and what must stay in the application code.
How we scope
- Written scope lists the APIs, routes and traffic patterns in the gateway's first phase.
- Each OWASP API risk is mapped to a gateway control, an application fix or a documented gap.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Scope names the identity provider, deployment mode and control plane location for the gateway.
How we build
- We deploy the chosen gateway, such as Apache APISIX or Kong Gateway, in your infrastructure.
- Authentication, rate limits, schema validation and logging are configured as code and kept in version control.
- We integrate the gateway with your existing identity provider and observability stack.
- Security testing of APIs checks the gateway policies and the object-level authorization left in the application.
How we hand over
- Deliverables include the API inventory, route and plugin configuration, and the risk mapping document.
- Runbooks cover upgrades, certificate rotation, backup and restore of gateway configuration.
- Your team receives documented gaps that require application-side work, with owners named for each one.
- Knowledge transfer sessions are scheduled as part of the written scope.
How we support
- Ongoing support, upgrades and continuous API testing are available as retainers.
- Gateway version upgrades are planned against the vendor's release and support policy for your chosen edition.
- Periodic re-testing checks new routes and plugins against the OWASP API Security Top 10 list.
- DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications.
