A curated list of the most important API security risks maintained by the OWASP API Security Project. It helps teams prioritise common failure modes such as broken authentication, object-level authorization, inventory gaps, and unsafe third-party consumption. The list is an awareness framework, not a complete control model.
What the OWASP API Security Top 10 is for
The OWASP API Security Top 10 is an awareness list, not a control standard. Its value is that it names the API failure modes teams most often miss in design, build, test and runtime operations, so security work can be prioritised around the places where APIs most commonly leak data, trust or authority.
Because APIs are often the connective tissue between services, applications and partners, the risks it highlights tend to be systemic rather than isolated. A single weakness in authentication, object-level checks or resource handling can expose many records, workflows or downstream integrations at once.
The risk classes the list is meant to surface
The list groups the API issues that recur across modern software delivery: broken authentication, broken object-level and function-level authorization, inventory gaps, unsafe consumption of third-party APIs, server-side request forgery, excessive consumption, and misconfiguration. Those failure modes matter because API traffic is usually machine-readable, high-volume and easy to automate against, which makes exploitation fast and scalable.
It is also a useful way to distinguish authentication failures from authorization failures. An API can authenticate a caller correctly and still leak data if object-level checks are weak, or it can enforce resource access correctly and still expose internal systems through a poorly controlled outbound call path.
How teams use the Top 10 in practice
Teams use the Top 10 as a review lens for design decisions, testing coverage and backlog prioritisation. It is most useful when paired with concrete API inventory, endpoint ownership, threat modelling and validation requirements, so that “known risky patterns” are checked against the APIs that actually exist rather than assumed to be covered by generic application security processes.
That is why a broader guide such as API Security Guide is useful alongside the list, and why a control-oriented resource such as Top 10 API Security Risks helps translate the awareness model into specific detections and preventive controls.
For endpoint-by-endpoint depth, the project’s items are often best studied individually. For example, OWASP API Top 10 API2 Broken Authentication Guide and OWASP API Top 10 API5 Broken Function Level Authorization Guide show how the same risk class can appear very differently at login, token validation, role enforcement and admin-path design.
Why API inventory and third-party consumption are part of the story
One reason the OWASP API Security Top 10 stays relevant is that many organisations do not know all of their exposed APIs, much less which ones are public, deprecated, shadowed or consumed by partners. Inventory gaps turn into security gaps when teams cannot answer which interfaces exist, who owns them, and whether they are still receiving traffic.
That same exposure can extend beyond the organisation’s own code. Unsafe consumption of third-party APIs, weak trust in upstream services, or SSRF-prone features can create indirect exposure even when the local application looks sound. A resource such as OWASP API Top 10 API7 Server-Side Request Forgery Guide is especially relevant where APIs fetch URLs, proxy requests or integrate with webhooks and metadata services.
For teams evaluating tooling, API Security Buyer's Guide is a practical companion because it frames discovery, testing, runtime protection and posture management as separate capabilities rather than a single product category.
How the list connects to standards and testing
Although the Top 10 is not itself a control model, it maps naturally to stronger verification work. Security requirements for authentication, session handling, authorization and validation are typically written in application security standards, then exercised through testing and review programmes. That is why teams often pair the list with OWASP ASVS for requirements depth and OWASP Web Security Testing Guide for structured verification.
The list is also best understood as a prioritisation aid for API-specific risk management, not as a substitute for secure design. Teams that treat it as a release checklist tend to overfocus on one or two headline risks and miss inventory, runtime exposure, or abusive consumption patterns that only show up when the whole API lifecycle is considered.
Risk and Threat Considerations
API weaknesses are attractive because they often provide direct, automatable access to data and business logic. A missed object-level check, weak authentication flow or unsafe outbound request can let an attacker enumerate records, pivot into internal systems or abuse trusted integrations at scale.
Failure mechanism: The underlying failure is usually not one bug but a broken assumption about who may act on which object, endpoint or downstream service. Once that assumption is wrong, the attacker can repeat the request pattern quickly and quietly across many resources.
Impact: The result can be bulk data exposure, unauthorized actions, service abuse, lateral trust abuse or hidden compromise of adjacent systems that rely on the API boundary for enforcement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | API risk categories align with API auth, authorization and validation requirements. |
| V8 — Authorization | Broken object and function authorization are core API Top 10 failure modes. | |
| V16 — Security Logging and Error Handling | API abuse and auth failures need detection and review signals. | |
| Recommendation — Use V4 to specify and verify API security requirements for authentication, authorization and request handling. Use V8 to enforce object- and function-level authorization checks on every API request. Use V16 to log authorization failures and anomalous API behaviour for investigation. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | API object and function access decisions depend on enforcing authorised access. |
| IA-5 — Authenticator Management | Broken authentication and token handling are central API risks. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | API abuse and authorization failures require reviewable telemetry. | |
| Recommendation — Enforce AC-3 so API requests are checked against policy before data or actions are returned. Apply IA-5 to manage API authenticators, secrets and token lifecycle securely. Review API audit records to spot abuse patterns, failed access attempts and anomalous consumption. | ||
| CIS Controls v8 | 5 — Account Management | API risk often stems from overprivileged or stale accounts and integrations. |
| 13 — Network Monitoring and Defense | API abuse and SSRF patterns require network and traffic monitoring. | |
| Recommendation — Inventory and govern API accounts, service identities and third-party access paths. Monitor API traffic for unusual destinations, volumes and request patterns. | ||
Practitioner Guidance
Why practitioners should care: The Top 10 is most useful when it drives ownership and prioritisation. Each category should map to a real team, a test expectation and a runtime detection path, otherwise the list becomes a poster instead of a control aid.
What to watch for: Treat unaudited endpoints, inconsistent authorization behaviour, unexpected third-party calls and unexplained spikes in API volume as signals that the risk model is incomplete. The best use of the list is to keep discovery, testing and enforcement aligned with the APIs that actually exist.
Related resources from NHI Mgmt Group
- How should security teams use the OWASP NHI Top 10 to prioritise risk reduction across service accounts, API keys, and OAuth apps?
- How should security teams prioritize fixes for the most common OWASP API Top 10 failures first?
- How should security teams integrate OWASP API Top 10 risks into the development lifecycle?
- What is the difference between OWASP Top 10 coverage and OWASP API Top 10 coverage for application security teams?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org