API management · Security controls
API security: what your gateway can enforce, and what only your services can
An API gateway enforces the same rules on every API in one place: who may call, how often, with what size and shape of request. It cannot decide whether this caller may read this particular record; only the service that owns the data can. This page maps the OWASP API Security Top 10 (2023) to the two places that have to handle them, lists the Kong controls for the gateway's part, and gives a release checklist your teams can use.
Published 6 min read
In short
- The gateway's job: authentication, rate and size limits, schema validation, access by consumer group, and one log of every call.
- The service's job: checking that the authenticated user may touch this object, this field and this function. The gateway cannot see your data model.
- The first risk in the OWASP list, broken object-level authorisation, is a service problem. A valid token asking for someone else's record passes every gateway check.
- Start with the inventory. An API the gateway does not know about is protected by none of its rules.
The OWASP API Top 10, and who handles each risk
| OWASP API Security risk (2023) | What the gateway can do | What must happen in the service or elsewhere |
|---|---|---|
| API1 Broken Object Level Authorization | Authenticate the caller and pass a verified identity to the service | Check, on every request, that this user may access this object ID |
| API2 Broken Authentication | Enforce one authentication method for all APIs; rate-limit login and token endpoints | Accept calls only through the gateway, so no service can be reached without it |
| API3 Broken Object Property Level Authorization | Validate requests against the API specification and reject unexpected properties | Return only the fields this user may see, and ignore fields they may not change |
| API4 Unrestricted Resource Consumption | Rate limits per consumer; request size limits; payload size checks | Pagination limits, timeouts, and caps on calls to paid third-party services |
| API5 Broken Function Level Authorization | Restrict routes, such as administrative ones, to named consumer groups | Check the user's role inside each function as well |
| API6 Unrestricted Access to Sensitive Business Flows | Per-consumer limits and bot detection on the routes that matter | Business rules such as per-account limits, and monitoring for unusual patterns |
| API7 Server Side Request Forgery | Little: the risk is in what the service fetches | Validate user-supplied URLs against an allow-list, and restrict outbound network access |
| API8 Security Misconfiguration | One place for TLS, CORS and headers, managed as reviewed configuration | Harden the services and platforms behind the gateway, and review the gateway's own configuration |
| API9 Improper Inventory Management | If all traffic must pass through it, the gateway's routes become a live inventory | Owners, versions and retirement dates for every API; close direct routes to services |
| API10 Unsafe Consumption of APIs | Little: the risk is in how your service trusts third-party responses | Validate data received from partner and third-party APIs as strictly as user input |
The split is not a ranking. Gateway controls are the quickest to roll out because they apply to every API at once; the service-side checks take longer because each team has to build them into its own code.
The risk a gateway cannot see
A customer signs in to your mobile app and requests /accounts/1234. The token is valid, the rate is normal and the request matches the specification, so every gateway check passes. If the customer changes the number to /accounts/1235 and the service returns another customer's account, nothing at the gateway was wrong: the gateway does not know who owns account 1235.
This is broken object-level authorisation, listed first in the OWASP API Top 10. It is fixed in the service, by checking ownership on every object access, and found by tests that try other users' IDs. A gateway is one component of an API security programme, not the whole programme.
Kong controls for the gateway's part
These are the Kong Gateway plugins that implement the gateway column above. Kong marks some of them as Enterprise only, which affects licensing; the list below reflects Kong's plugin catalogue on 2 November 2026.
| Control | Kong plugins | Licensing as listed by Kong |
|---|---|---|
| Authentication | Key Auth, JWT, OAuth 2.0 Authentication, Basic Auth | Not marked Enterprise only |
| Authentication with your identity provider, or with client certificates | OpenID Connect; Mutual TLS Authentication | Enterprise only |
| Access by consumer group | ACL | Not marked Enterprise only |
| Allow or deny by IP address | IP Restriction | Not marked Enterprise only |
| Rate limits | Rate Limiting; Rate Limiting Advanced | Rate Limiting Advanced is Enterprise only |
| Request size | Request Size Limiting | Not marked Enterprise only |
| Validation against the API specification | Request Validator; OAS Validation (requests and responses) | Enterprise only |
| Payload checks | Injection Protection (pattern-based); JSON Threat Protection and XML Threat Protection (size checks) | Enterprise only |
| Automated clients | Bot Detection | Not marked Enterprise only |
| Browser access rules | CORS | Not marked Enterprise only |
Every route, plugin and consumer should be defined in version-controlled configuration and changed only through review. Kong licensing, where the enterprise edition is needed, is quoted on Kong's terms.
The order we work in
The gateway is step three, not step one.
-
Inventory.
Every API, its owner, its consumers and how it authenticates today, including the ones nobody has documented.
-
Policy.
One authentication method per consumer type, rate limits set from real consumers rather than defaults, which routes are administrative, and what is logged.
-
Gateway.
Deploy the controls above as reviewed configuration, and switch off direct routes to services.
-
Test.
Authorisation tests that try other users' object IDs, fields and functions, alongside the gateway tests.
-
Monitor.
Watch rejected requests, rate-limit hits and authentication failures per consumer, and give each alert an owner.
A checklist for your next API release
- The API is in the inventory, with an owner and a version.
- It is reachable only through the gateway.
- Authentication is configured at the gateway, using the agreed method for this consumer type.
- Rate and size limits are set for each consumer, from expected usage.
- Requests are validated against the published specification.
- The service checks object ownership on every request that takes an ID.
- Responses contain only the fields this caller may see.
- Administrative functions are on separate routes, limited to named consumer groups.
- Tests include another user's IDs, and fail if any data comes back.
- Rejections and authentication failures are logged and someone reviews them.
How Interkey helps
Interkey implements and operates Kong for organisations in Saudi Arabia, from Riyadh, in Arabic and English. We start with the API inventory, write the gateway policy with your security team, deploy Kong self-managed in the Kingdom or in a hybrid shape, and move consumers onto it. Where we also build or integrate the services behind the gateway, the ownership and role checks in the right-hand column of the table are part of that work. Penetration testing and round-the-clock security monitoring sit with your security team or a specialist provider; we make sure the gateway logs give them what they need.
Questions buyers ask
Is an API gateway the same as a web application firewall?
No. A gateway enforces API-specific rules: who the consumer is, which routes it may call, how often, and whether requests match the specification. A web application firewall inspects traffic for attack patterns. Many organisations run both, and each needs its own rules.
Does a gateway replace penetration testing?
No. It enforces the controls you configure. Testing finds what is missing, including authorisation flaws inside services that no gateway can see.
Which Kong features need an enterprise licence?
Kong's plugin catalogue marks OpenID Connect, Mutual TLS Authentication, Rate Limiting Advanced, request and specification validation, and payload threat protection as Enterprise only. Key and token authentication, basic rate limiting, size limits, ACLs, IP restriction and bot detection are not marked that way. Check the catalogue for the version you deploy.
Can the gateway run inside the Kingdom?
Yes. Kong can run self-managed on infrastructure in the Kingdom, so both API traffic and gateway configuration stay there. See Kong implementation and operations.
Where should we start?
With the inventory. It is a matter of weeks, and every later step depends on it.
Next
Related pages
Next step
Start with what you actually expose
Tell us roughly how many APIs you run, who calls them, and how they authenticate today. A specialist from the Riyadh team replies on Saudi working days, in Arabic or English.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia