API management · API threats

OWASP API Security Top 10: each risk, what a gateway enforces, and what your code must fix

The OWASP API Security Top 10 is the list most security reviews, security test reports and procurement questionnaires use for API threats. This guide takes the ten risks one at a time: what goes wrong, which gateway control helps (authentication, schema validation, rate limits, logging), what still needs a code fix, and how to test for it, with a map of each risk to Kong Gateway plugins.

Published November 10, 2026 9 min read

The ten risks are described in our own words; the official wording is on the OWASP site. Kong plugin names as listed on Kong's plugin catalogue on 2 November 2026.

Review your APIs against the OWASP list Risks mapped to Kong plugins

Orientation

At a glance

The whole page in one table, before the detail.

What it is: OWASP's list of the ten most common security risks in APIs, last revised in 2023
Who uses it: Security reviewers, security testers, auditors and buyers writing API requirements
What a gateway covers: Authentication, rate and size limits, schema validation, consumer groups, logging
What it cannot cover: Whether this user may read this record or field, or call this function
Saudi angle: PDPL and NCA controls; traffic can stay in the Kingdom
Where Kong fits: The gateway half of each risk, on every API at once

The problem in plain words

Why it matters: APIs carry most of the data your apps and partners exchange, and attackers call them directly, without the screens that hide fields.
What most findings share: a genuine, signed-in caller asks for what it should not get: another customer's record, an admin function, a protected field.
What a gateway does: the same checks on every API at once, the fastest way to close half of each risk.
What it does not do: see your data model; authorisation is fixed in code and proved by tests.

What the OWASP API Security Top 10 is, and how to read it

OWASP, the Open Worldwide Application Security Project, is a non-profit community that publishes free security guidance. Its API Security project keeps a top ten list separate from its web application list, because APIs fail differently: they expose object IDs in every URL, return whole records and leave the client to hide fields, and are called by scripts rather than people. The current edition dates from 2023. We describe each risk in our own words; use the OWASP site for the official names and numbering in requirements or audits.

Read the list as questions to ask of every API, not ten products to buy. Four risks concern authorisation and authentication, where most incidents start; the other six concern limits, abuse and the estate as a whole. For a one-table summary and a release checklist, see our API security overview.

Authorisation and authentication risks: where most API breaches start

Broken object level authorization

A signed-in user changes an ID in the request, /orders/1001 to /orders/1002, and the API returns someone else's order. The token is valid and the request is well formed, so every gateway check passes. Gateway: authenticate the caller and pass a verified identity to the service. Code fix: on every request that takes an ID, check that this identity owns or may access that object; avoid relying on IDs being hard to guess.

Broken authentication

Weak or inconsistent sign-in: tokens that never expire, login and password-reset endpoints with no attempt limit, internal APIs that accept calls with no credential. Gateway: one agreed authentication method per consumer type on every route, and rate limits on login and token endpoints. Code fix: services accept traffic only through the gateway, and credential handling stays in your identity provider.

Broken object property level authorization

The API returns the whole record, national ID and salary included, and trusts the app to hide fields; or it accepts a field such as role or balance that the user should never set. Gateway: validate requests against the published specification and reject undeclared properties. Code fix: return only the fields this caller may see, and bind updates to an explicit list of fields each role may change.

Broken function level authorization

A normal user calls an administrative endpoint, or a DELETE where only GET was meant, and the service runs it. Gateway: restrict administrative routes and methods to named consumer groups, and keep admin APIs off public routes. Code fix: check the caller's role inside each function too, because a route rule protects only the paths it knows about.

Limits, abuse and estate risks: the other six API threats

Unrestricted resource consumption

No limit on call rate, request size or page size, so one client can slow the API for everyone or run up the bill for paid services behind it, such as SMS or identity checks. Gateway: rate limits per consumer and request size limits; our guide to API rate limiting covers how to set them. Code fix: page size caps, timeouts, and limits on calls to paid third-party services.

Unrestricted access to sensitive business flows

Each call is legitimate, but a script repeats it at a scale no person would: booking every appointment slot, claiming every promotion, creating accounts in bulk. Gateway: tighter per-consumer limits and bot detection on those routes. Code fix: per-account or per-device business rules, and monitoring for patterns no single request shows.

Server-side request forgery

The API fetches a user-supplied URL, for a webhook or an image, from inside your network, where it can reach internal services or cloud metadata endpoints. Gateway: little; the danger is in what the service fetches. Code fix: validate user-supplied URLs against an allow-list and restrict the service's outbound network access.

Security misconfiguration

Verbose error messages, permissive CORS, missing TLS on internal hops, default settings, open debug endpoints. Gateway: one place for TLS, CORS and response headers, as reviewed, version-controlled configuration. Code fix: harden the services and platforms behind it, and review the gateway's own configuration like code.

Improper inventory management

Old versions still running, test hosts on the internet, partner APIs nobody owns. Gateway: if every call must pass through it, its routes become a live inventory. Code fix: owners, versions and retirement dates for every API, and direct routes to services closed.

Unsafe consumption of APIs

Your service trusts a partner API's response more than a user's input, and passes it straight to a database or screen. Gateway: little; the risk sits in your outbound calls. Code fix: validate third-party responses as strictly as user input, use TLS for every outbound call, and limit redirects. The same thinking applies to language models your services call; see what an AI gateway can and cannot stop.

OWASP API risks mapped to Kong Gateway plugins

Plugin names and Enterprise-only markings as Kong's plugin catalogue listed them on 2 November 2026; check the catalogue for the version you deploy.

Each OWASP API Security risk mapped to the Kong Gateway plugins that help and the fix that stays in code
Risk, in plain words	Kong Gateway plugins that help	What stays in the service code
Object level authorisation	Key Auth, JWT, OAuth 2.0 Authentication, OpenID Connect (Enterprise only) to pass a verified identity	Ownership check on every object ID
Authentication	Key Auth, JWT, OAuth 2.0 Authentication, Basic Auth; OpenID Connect and Mutual TLS Authentication (Enterprise only); Rate Limiting on login routes	Services reachable only through the gateway
Object property level authorisation	Request Validator and OAS Validation, which checks requests and responses (Enterprise only)	Field-level filtering of responses; allow-listed updatable fields
Resource consumption	Rate Limiting; Rate Limiting Advanced (Enterprise only); Request Size Limiting; JSON Threat Protection and XML Threat Protection (Enterprise only)	Page size caps, timeouts, limits on paid downstream calls
Function level authorisation	ACL by consumer group; IP Restriction for administrative routes	Role check inside each function
Sensitive business flows	Rate Limiting or Rate Limiting Advanced per consumer; Bot Detection	Per-account business rules and pattern monitoring
Server-side request forgery	None directly	URL allow-lists; outbound network restrictions
Security misconfiguration	CORS; Injection Protection, pattern-based (Enterprise only); TLS and headers in reviewed configuration	Hardened services and platforms
Inventory management	Routes and services as the live inventory, managed declaratively with decK	Owners, versions, retirement dates
Unsafe consumption of APIs	None directly	Validation of every third-party response

Kong's logging plugins send every call to your observability platform, so rejected requests, rate-limit hits and authentication failures become alerts with owners.

API security testing: how to prove each risk is closed

Gateway rules are easy to check once; authorisation needs tests that run on every release.

Two-user tests. Sign in as user A, request user B's object IDs, fields and functions; every request must fail.
Role tests. Call every administrative route and method with a normal user's token.
Mass-assignment tests. Send fields the specification does not allow in create and update requests.
Limit tests. Exceed each rate and size limit, and confirm the rejection is logged against the right consumer.
Specification drift. Compare what each API returns with its published specification.
Inventory sweep. Find hosts and versions that answer without the gateway.
Outbound tests. Put internal addresses in URL fields; the service must refuse them.

Why API security matters for organisations in Saudi Arabia

Banks, fintechs, government entities and retailers in the Kingdom open more APIs to partners and mobile apps each year, many carrying national ID, Iqama, mobile and payment data. Personal data falls under the Personal Data Protection Law, overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA); see our PDPL overview. The National Cybersecurity Authority (NCA) publishes the cybersecurity controls many organisations must meet; our page on the NCA Essential Cybersecurity Controls gives the general picture. Which requirements apply to you is for your compliance owner to confirm from the authorities' own texts.

The OWASP list turns those obligations into work an auditor can follow: each risk becomes a gateway rule, a code change and a test with an owner. Where API traffic and logs must stay in the Kingdom, Kong can run self-managed on infrastructure you operate there, supported by Interkey from Riyadh in Arabic and English.

Where Kong fits in API security, and where it does not

Kong is a technology partner whose gateway Interkey implements and operates. In this guide it takes the gateway half of each risk: authentication, consumer groups, rate and size limits, specification validation and logging, defined once and applied to every API it fronts. Our API gateway guide explains the deployment options.

Where it does not fit: Kong does not know who owns order 1002, which fields a support agent may see, or what your service does with a URL a user supplied. Those are code fixes, and no gateway replaces authorisation logic or independent security testing. If you have a handful of APIs behind one application with its own access checks, a gateway may not be the first thing to buy; we will say so.

How Interkey helps

Interkey's API management practice starts from your APIs: an inventory with owners, a review against the ten risks, Kong configuration for the gateway half, and code fixes and tests for each service team. Kong licensing is quoted on Kong's terms, on a separate line from Interkey's work.

Questions teams ask about the OWASP API Security Top 10

What is the OWASP API Security Top 10?

It is a list, published by the OWASP community, of the ten most common security risks in APIs, with examples and ways to prevent each. The current edition dates from 2023. Security reviews, security tests and procurement questionnaires often use it as their checklist.

Which OWASP API risk causes the most breaches, and can a gateway stop it?

Broken object level authorisation, a signed-in user reaching another user's record by changing an ID, is listed first and is common. A gateway cannot stop it alone, because the request is valid; the service must check ownership on every object access.

Does an API gateway make us compliant with the OWASP API Top 10?

No. OWASP publishes guidance, not a certification, and a gateway covers only part of each risk. Authorisation, field filtering and outbound validation need code fixes and tests in every service.

Which Kong plugins do we need, and do they need an enterprise licence?

Most estates start with an authentication plugin, ACL, Rate Limiting and Request Size Limiting, which Kong does not mark Enterprise only. Specification validation, OpenID Connect, Mutual TLS Authentication and threat protection are Enterprise only. Licensing is quoted on Kong's terms.

How long does an OWASP API review take for a Saudi organisation?

It is estimated per project, from the number of APIs, whether an inventory and specifications exist, and how many teams must fix code. Gateway controls can go live before every code fix is done.

Can API traffic and logs stay in Saudi Arabia with Kong?

Yes. Kong can run self-managed on infrastructure you operate in the Kingdom, so API traffic, gateway configuration and logs stay there. Where they must stay is a decision for your data classification, and support comes from Riyadh.

Next step

Review your APIs against the OWASP API Security Top 10

Tell us how many APIs you expose, who calls them, and any recent security findings. We reply with which risks gateway configuration can close, which need code fixes, and a first scope.

First name Last name

Company Email Company

Phone number (optional) What are you working on? (optional)

Required field

By sending this form, you agree to our Privacy Notice.

Published by Interkey. Last updated 2026-11-10. Interkey is registered in Riyadh, Saudi Arabia under commercial registration 1010156897.