Standards explained
OWASP API Security Top 10 (2023) Explained
APIs have their own OWASP Top 10, reflecting that API risk is dominated by authorization and business-logic flaws rather than classic injection. Here is the 2023 edition explained.
API1: Broken Object Level Authorization
Missing per-object authorization (IDOR/BOLA) - the most common and impactful API flaw.
API2: Broken Authentication
Weak token issuance or validation, allowing attackers to assume identities.
API3: Broken Object Property Level Authorization
Mass assignment and excessive data exposure - reading or writing properties a client should not access.
API4: Unrestricted Resource Consumption
Missing rate, size, or pagination limits, enabling denial of service and cost abuse.
API5: Broken Function Level Authorization
Low-privileged users reaching privileged or admin functions via forced browsing.
API6: Unrestricted Access to Sensitive Business Flows
Automatable sensitive flows (purchases, invites) abused at scale without safeguards.
API7: Server Side Request Forgery
APIs fetching attacker-influenced URLs, reaching internal and cloud metadata services.
API8: Security Misconfiguration
Insecure defaults, missing headers, verbose errors, and permissive CORS.
API9: Improper Inventory Management
Undocumented, deprecated, or shadow endpoints and environments that widen the attack surface.
API10: Unsafe Consumption of APIs
Trusting third-party APIs without validating their responses, importing their risk.
Key takeaways
- Authorization (API1, API3, API5) is the dominant API risk theme.
- Inventory gaps - shadow and deprecated APIs - are a leading exposure.
- Business-flow abuse requires reasoning about intent, not signatures.
FAQ
Why does the API Top 10 emphasize authorization so heavily?
APIs expose object and function references directly, without a UI to constrain them, so missing per-object and per-function authorization is both easy to introduce and highly impactful. Three of the ten categories are authorization-related.
Related
Impactr finds and proves whether flaws like this are actually reachable in your own web apps and APIs, with a reproducible exploit as evidence.