API security matters more than ever because APIs now carry most application traffic and expose business logic and data directly. Attackers do not need a browser or a user interface. They can call an endpoint with a changed identifier and see whether the server notices.
Why are APIs a different problem?
A web page hides most logic behind a form. An API publishes it. Each endpoint tells a client how to ask for data, and mobile apps, partner integrations and single page applications all talk to the same set of endpoints. That brings three pressures:
- Volume. Organizations run hundreds of endpoints, many created quickly and some forgotten.
- Trust in the client. Developers sometimes assume only their own app calls the API, and skip checks on the server.
- Direct access to objects. Endpoints often take an identifier, such as an order number, that maps straight to a database record.
What does the OWASP API Security Top 10 say?
The 2023 edition of the OWASP API Security Top 10 lists these risks:
- Broken Object Level Authorization
- Broken Authentication
- Broken Object Property Level Authorization
- Unrestricted Resource Consumption
- Broken Function Level Authorization
- Unrestricted Access to Sensitive Business Flows
- Server Side Request Forgery
- Security Misconfiguration
- Improper Inventory Management
- Unsafe Consumption of APIs
Notice how many are about authorization and logic rather than classic injection. A tool that only looks for malformed input will miss most of them, because the requests are well formed and the server is simply too generous.
What does the top risk look like?
Broken object level authorization is the leading entry, and it is simple. A constructed example: a user opens their invoice at an address ending in 1001. They change the number to 1002 and receive another customer's invoice, because the server checked that the user was logged in but not that invoice 1002 belongs to them.
The fix is a check on every request that the signed in user may access that specific object, done on the server. Random identifiers make guessing harder, but they do not replace the check.
What about the other risks?
- Broken authentication covers weak login, token handling and password reset flows.
- Object property level problems appear when an API returns more fields than the client needs, or accepts fields the client should not set, such as a role flag.
- Resource consumption means no limits on request rate, payload size or expensive queries, which can cause outages and cost.
- Function level issues let an ordinary user call an administrator function by guessing its path.
- Sensitive business flows are abused when automation can buy up stock or create accounts at scale.
- Inventory problems mean old versions and test endpoints stay online, unmonitored.
- Unsafe consumption is trusting data from third party APIs as if it were safe.
How do you find these problems early?
Different checks find different problems.
- Design review finds missing authorization rules before code is written.
- Contract checks compare the published description of the API with what actually runs, which exposes forgotten endpoints.
- Automated tests with two test users catch object level problems: user A requests user B's data and expects a refusal.
- Static and dependency analysis catch injection flaws and vulnerable libraries in the services behind the API.
- Runtime monitoring spots unusual patterns such as one client walking through many identifiers.
How to check or apply this
- Build an inventory of every API and version in production, including internal ones and ones called by partners.
- For each endpoint that takes an identifier, write a test that proves a second user cannot access the first user's object.
- Set rate limits and maximum payload sizes by default in your gateway or framework.
- Return only the fields each client needs, using explicit response models.
- Retire old versions with a published date.
- Log authorization failures and alert on spikes.
Quick check
Is an API gateway enough to secure APIs?
No. A gateway can enforce authentication and limits, but object and function level authorization usually depends on application logic behind it.
What is the most common API flaw?
OWASP ranks broken object level authorization first in its 2023 list.
Sources
Last reviewed: 18 October 2026.
