By Cyber Defense Technologies October 26, 2026 4 min read
Mobile apps, single-page web applications, partner integrations and AI agents all depend on APIs. The user interface may hide fields or buttons, but an attacker does not use the interface. They call the API directly, change parameters and see what comes back.
That makes APIs a direct path to data and business logic, and many API weaknesses are not the kind that traditional network scanners find.
Why APIs need their own attention
The OWASP API Security Top 10 exists because API risks differ from those of traditional web pages. Its categories include broken object level authorization, broken authentication, broken function level authorization, unrestricted resource consumption, security misconfiguration and improper inventory management. It is a useful checklist for designers, developers and testers, and a common reference in testing contracts.
Start with an inventory
API inventories go stale quickly. Two problems are common:
- Shadow APIs, endpoints that are running but were never documented or reviewed, often added for a quick integration or a debugging need.
- Zombie APIs, old versions that were replaced but never turned off. They frequently lack the fixes and controls added to newer versions.
Build the inventory from several sources: API gateway configuration, API specifications, cloud resources, code repositories and traffic logs. Record the owner, the data each API handles, who is meant to call it and whether it is exposed to the internet. Retire old versions on a published schedule. A gateway helps, but only for traffic that passes through it, so look for APIs exposed directly from application servers and cloud functions as well.
Check authorization on every object
Broken object level authorization is the first entry in the OWASP API Security Top 10, and for good reason. It happens when an API checks that the caller is logged in but not that the caller is allowed to access the specific record requested. Changing an account number or document ID in a request returns someone else's data.
- Enforce authorization on the server for every request, for every object, based on the authenticated identity.
- Check function-level permissions too, so ordinary users cannot call administrative operations simply by guessing the route.
- Return only the fields the caller needs, rather than whole records filtered by the client.
- Centralize authorization logic so it is applied consistently rather than reimplemented in each endpoint.
Unpredictable identifiers make guessing harder but are not a substitute for authorization checks.
Authenticate properly
Use established standards and libraries for API authentication rather than custom schemes. Validate tokens fully, including signature, issuer, audience and expiry. Keep token lifetimes short, protect refresh tokens and make revocation possible. API keys identify an application, not a user, so do not rely on them alone to protect user data. Apply the same protections against credential stuffing to login and token endpoints as to the main sign-in page.
Limit abuse
Even a correctly authorized API can be abused at scale. Automated clients can scrape data, test stolen credentials, run up cloud costs or exhaust resources.
- Rate limits and quotas per user, per key and per source.
- Limits on request size, page size, batch operations and query complexity.
- Extra protection for sensitive business flows, such as account creation, password reset or purchasing, which may need step-up verification or bot detection.
- Timeouts and resource limits on back-end processing.
Log and monitor API activity
Log authentication events, authorization failures, the identity behind each request, the objects accessed and unusual volumes. A single user requesting thousands of sequential record IDs is a strong signal of enumeration. Send API logs to central monitoring, and make sure they do not record tokens, passwords or sensitive data in plain text.
Test APIs the way attackers use them
Include APIs explicitly in penetration tests and code reviews. Provide testers with specifications and accounts at different privilege levels so they can check whether one user can reach another's data. Add authorization tests to automated test suites, so a regression is caught before release rather than after.
Do not forget the APIs you consume. Data returned by partner and third-party APIs should be treated as untrusted input and validated, and URLs or redirects supplied by an external API should not be followed without checks.
How CDT can help
CDT tests APIs the way adversaries approach them. Our penetration testing team examines authorization, authentication and abuse cases across your APIs, and our code review specialists find authorization flaws in the source before they reach production.
