Top 10 API Security Risks: The OWASP API Security Top 10 Explained

Most serious API flaws are not exotic bugs: they are authorisation checks that were never written, limits that were never set and endpoints nobody remembers deploying. The OWASP API Security Top 10 is the reference list of top API security risks, and the 2023 edition, released as stable on 5 June 2023, is still the current one: OWASP's project page announces no newer edition. This page works through each item of the OWASP API Top 10 2023, from API1:2023 Broken Object Level Authorization to API10:2023 Unsafe Consumption of APIs: OWASP's ratings, a real example, how to detect it and the controls that prevent it, then a mapping to the OWASP Top 10:2025, ASVS 5.0 and CWE. It is for API developers, AppSec engineers, testers and platform owners. For the wider picture, including token choices, gateways and protocol specifics, see the API Security Guide.

The Top 10 at a glance

Ratings are OWASP's own, from each 2023 risk page. OWASP's call for data received no contributions, so the list rests on team experience, specialist review and community feedback: treat it as an API security risks list for awareness and test planning, not a measured ranking of top API vulnerabilities.

1. API1:2023 Broken Object Level Authorization (BOLA)

What it is: an endpoint takes an object identifier from the caller (a path segment, query parameter or GraphQL argument) and acts on that object without checking the caller may do so. OWASP rates it Easy to exploit and Widespread, and warns that comparing the session user ID with an ID in the request covers only a small subset of cases. It maps to CWE-639 Authorization Bypass Through User-Controlled Key and CWE-285 Improper Authorization; older material calls it insecure direct object reference (IDOR).

Real example: OWASP's scenarios include a shop revenue endpoint enumerated by shop name and a connected-car API that accepts any vehicle identification number. The McHire default password flaw combined a default credential with an IDOR, the BOLA pattern at its simplest.

How to detect it: one identity requesting many distinct or sequential object IDs; a rising ratio of 403 and 404 responses per client; a single token reading objects across tenants. In testing, use two users per role and tenant and assert neither can touch the other's objects; scanners rarely find BOLA.

Controls that prevent it: resolve the object, compare its owner or tenant with the subject from the validated token (never from a request field), and refuse consistently. OWASP adds random, unpredictable record IDs as a speed bump, not a control, and tests that "evaluate the vulnerability of the authorization mechanism" as a release gate. ASVS 5.0 requirement v5.0.0-8.2.2 (Level 1) covers data-specific access and names IDOR and BOLA. See the Broken Access Control Prevention Guide.

2. API2:2023 Broken Authentication

What it is: the API cannot reliably tell who is calling. OWASP's list includes credential stuffing, brute force with no lockout, tokens in URLs, sensitive changes without password confirmation, unchecked token signature or expiry, JWTs accepted with "alg":"none", and microservices reachable without authentication.

Real example: OWASP describes a login limited to three requests a minute that is bypassed by batching many GraphQL login attempts into one request, and an email change that needs no current password, which turns a stolen token into a full account takeover through the reset flow. The Gravity SMTP CVE-2026-4020 exposure shows the bluntest form: an open REST endpoint that handed stored email API keys to anyone who asked.

How to detect it: failed authentication bursts on login, OTP and reset endpoints; token validation failures by reason (signature, audience, expiry); one token or client ID seen from new networks; and endpoints returning 200 to requests carrying no credential.

Controls that prevent it: OWASP is blunt: "OAuth is not authentication, and neither are API keys", and "API keys should not be used for user authentication." Use a standard identity provider and OpenID Connect for users, validate iss, aud, exp and the algorithm from configuration rather than the token header, treat reset endpoints like login for rate limiting and lockout, and "Require re-authentication for sensitive operations". For machine callers, use short-lived, audience-bound tokens or mTLS instead of shared static keys. See the Token and Session Security Guide and the NHI Authentication Guide.

3. API3:2023 Broken Object Property Level Authorization (BOPLA)

What it is: the caller may access the object but not every property of it. The 2023 edition merged the 2019 items Excessive Data Exposure (reading properties you should not see) and Mass Assignment (writing properties you should not change) because they share one root cause: OWASP's release notes call it "object property level authorization validation failures".

Real example: OWASP's scenarios include a dating app whose report-user mutation returned the reported person's full name and recent location, a marketplace host who added a total_stay_price field to a booking approval to overcharge the guest, and a user who unblocked their own rejected video by adding "blocked": false to an update. The OneLogin API flaw (CVE-2025-59363) exposed OIDC client secrets to anyone holding an API key, the read side of the same problem.

How to detect it: response schema validation in report mode at the gateway flags properties not in the published contract; diff response sizes per endpoint after releases; in code review, search for generic serialisers and auto-binding of request bodies to persistence models.

Controls that prevent it: avoid generic serialisers such as to_json(), define explicit response objects per role, keep an allowlist of writable properties per operation, set additionalProperties: false in request schemas, and validate responses as an extra layer. ASVS v5.0.0-8.2.3 (Level 2) limits field-level access and names BOPLA; v5.0.0-8.1.2 asks you to document field-level read and write rules first.

4. API4:2023 Unrestricted Resource Consumption

What it is: requests cost CPU, memory, bandwidth, storage and, increasingly, money paid to providers per call. OWASP lists the limits whose absence makes an API vulnerable: execution timeouts, maximum memory, file descriptors, processes, upload size, operations per request (for example GraphQL batching), records per page, and third-party spending limits.

Real example: OWASP's scenarios include password-reset SMS messages billed at $0.05 each and a cloud bill that rose from about $13 to about $8,000 a month after a file outgrew its cache. AI model APIs behind your endpoints add the same exposure: see the LLMjacking Guide.

How to detect it: 429 rates by client, request and response size outliers, page sizes above policy, and provider billing alerts per integration.

Controls that prevent it: "Define and enforce a maximum size of data on all incoming parameters and payloads", rate limit per identity and tenant (not only per IP), throttle OTP and recovery flows harder than general traffic, cap page sizes server-side, set container or serverless resource limits, and "Configure spending limits for all service providers/API integrations". CWE-770, CWE-400 and CWE-799 apply.

5. API5:2023 Broken Function Level Authorization (BFLA)

What it is: a caller reaches a function their role should not have. OWASP's test questions are practical: can a regular user reach administrative endpoints, perform a destructive action by changing GET to DELETE, or call another group's function by guessing its URL? It warns that admin endpoints often sit under ordinary paths such as /api/users, not /api/admin.

Real example: in OWASP's invite scenario, an attacker replays an invite lookup against an admin-only invite creation endpoint that has no role check, issues themselves an admin invite and creates an admin account.

How to detect it: non-admin identities calling admin routes or unusual methods, 405 and 403 spikes by method, and route inventories compared with authorisation policy. Test every route with every role and every method.

Controls that prevent it: enforcement that will "deny all access by default", explicit grants per role, administrative controllers that inherit from a base controller performing role checks, and separate admin APIs, hosts or audiences. ASVS v5.0.0-8.2.1 limits function-level access to consumers with explicit permissions, and v5.0.0-4.1.4 (Level 3) blocks HTTP methods that are not explicitly supported.

6. API6:2023 Unrestricted Access to Sensitive Business Flows

What it is: every request is valid, but automating the flow at scale harms the business: buying, booking, posting, signing up or redeeming. OWASP notes this risk often comes from design choices rather than coding bugs, which is why scanners miss it.

Real example: OWASP describes console scalping across many IP addresses, one user booking 90% of a flight's seats to force fare cuts, and scripted sign-ups farming referral credit.

How to detect it: machine-speed sequences (OWASP's example is add to cart and checkout in under a second) and many accounts sharing devices or payment details.

Controls that prevent it: first identify which flows would hurt if used excessively, then layer device fingerprinting (refusing unexpected clients such as headless browsers), human detection, non-human pattern analysis and, as OWASP suggests, consider blocking Tor exit nodes and well-known proxies. See the Bot Management Guide.

7. API7:2023 Server Side Request Forgery (SSRF)

What it is: the API fetches a URL the caller supplied without validating it, so the server sends requests to destinations the attacker cannot reach directly, including behind firewalls and VPNs. OWASP names webhooks, file fetching from URLs, custom SSO and URL previews as growing sources, and cloud, Kubernetes and Docker management interfaces on predictable HTTP paths as the prize. CWE-918.

Real example: OWASP's webhook scenario points a test notification at a cloud metadata service and reads the returned credentials in the API's response. The Capital One breach is the canonical case of SSRF turning into stolen cloud role credentials.

How to detect it: egress from API workloads to private ranges, link-local metadata addresses or unexpected ports, and cloud role credentials used from outside the workload that owns them.

Controls that prevent it: isolate the fetching component in the network, allowlist origins, schemes, ports and media types, "Disable HTTP redirections.", use one well-tested URL parser, and "Do not send raw responses to clients." Enforce token-based metadata access on cloud instances. See the SSRF Prevention Guide.

8. API8:2023 Security Misconfiguration

What it is: any layer configured unsafely: missing hardening or patches, unneeded HTTP verbs, no TLS, missing cache and security headers, permissive CORS, stack traces in errors, or proxies and servers that parse requests differently (the root of request smuggling). OWASP rates it Widespread and Severe.

Real example: OWASP cites a logging library with insecure defaults that expanded a malicious header into a remote class lookup, and a messaging API whose responses lacked cache directives, leaving private conversations in browser caches.

How to detect it: configuration scanning of gateways, orchestration files and cloud services, header and TLS checks on every hostname, and alerts on error responses that leak stack traces.

Controls that prevent it: a repeatable hardening baseline, TLS on internal as well as public traffic, being "specific about which HTTP verbs each API can be accessed by", restricted content types, a specific CORS origin list, and defined response schemas including errors. ASVS v5.0.0-4.2.1 requires all components to agree on message boundaries to prevent smuggling. See the Web Application Firewall Guide for what an edge layer can and cannot cover.

9. API9:2023 Improper Inventory Management

What it is: OWASP describes two blindspots. A documentation blindspot (unknown environment, audience or version, and no retirement plan for old versions) and a data flow blindspot (sensitive data sent to a third party with no recorded justification or visibility). CWE-1059 Incomplete Documentation.

Real example: in OWASP's scenario a beta host ran the same API without the rate limiting production relied on, so a six-digit reset token could be brute forced. The T-Mobile API breach, where one abused API leaked data on 37 million accounts, shows how much a single poorly governed endpoint can expose.

How to detect it: compare observed traffic (gateway, load balancer and mesh logs) with the registered inventory; the difference is your shadow API list. Count deprecated versions still receiving calls past their sunset date, and external scans of non-production hostnames.

Controls that prevent it: inventory every host and integrated service with owner, environment, audience, version and data class; "Generate documentation automatically by adopting open standards" in the pipeline; restrict documentation to authorised users; keep production data out of non-production; and backport security fixes to old versions or switch them off. See the Attack Surface Management Guide.

10. API10:2023 Unsafe Consumption of APIs

What it is: developers trust data from third-party APIs more than user input, so attackers target the integrated service instead. OWASP lists unencrypted calls to third parties, no validation or sanitisation of their data, following redirects blindly, and no resource limits or timeouts on third-party responses. CWE-20, CWE-200 and CWE-319.

Real example: OWASP's scenarios include an injection payload planted in a record at an enrichment service and later executed by the consuming API, and a compromised partner that answered with a 308 redirect so the client resent sensitive medical data to the attacker's server. The identity side of the same trust shows in the Salesloft Drift breach, where tokens held by one integration opened hundreds of customer tenants.

How to detect it: schema validation failures on inbound partner data, redirects from third-party endpoints to hosts outside the allowlist, timeouts and oversized responses per integration, and egress to destinations no integration is registered for.

Controls that prevent it: "assess their API security posture" when choosing providers, TLS for every integration, validate partner responses against a schema as strictly as user input, "Maintain an allowlist of well-known locations integrated APIs may redirect" to, set timeouts and size limits, and give each integration its own scoped, rotated credential. See the Third-Party Risk Management Guide and the API Key Management Guide.

Mapping to OWASP

Against 2019, the 2023 list merged Excessive Data Exposure and Mass Assignment into API3, turned Lack of Resources and Rate Limiting into Unrestricted Resource Consumption, renamed Broken User Authentication and Improper Assets Management, and added Sensitive Business Flows and Unsafe Consumption. The 2019 Injection and Insufficient Logging and Monitoring items no longer appear (OWASP gives no reason); both still matter, and API10 is often how injection now reaches an API. In the table, CWE IDs are OWASP's references; the OWASP Top 10:2025 and ASVS 5.0 columns are our mapping. OWASP Top 10:2025 rolled SSRF into A01 Broken Access Control.

Beyond OWASP: NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems, organises API controls into pre-runtime and runtime stages, and its March 2026 update adds Appendix D (API risks by category) and Appendix E (recommended controls by lifecycle stage). In NIST SP 800-53 Rev. 5, map API1, API3 and API5 to AC-3 and AC-6, API4 to SC-5, API7 and API10 to SI-10, and API9 to CM-8. ATT&CK records the initial access these flaws enable as T1190 Exploit Public-Facing Application. The OWASP Top 10 Guide covers the web list.

Where to start

If you can do only three things this quarter: build an inventory from traffic and code and switch off what nobody owns (API9), write cross-user and cross-tenant authorisation tests for every object and admin endpoint and make them a release gate (API1, API3, API5), and set size, page, rate and spending limits on every public API (API4). Those three cover the items OWASP rates Widespread and the ones gateways cannot fix for you.

1. Inventory (weeks 1 to 6): pull routes from gateways, code and OpenAPI files, compare with traffic, assign owners and rank APIs by exposure.
2. Close the obvious: unauthenticated non-public endpoints and zombie versions first. Log callers with deprecation headers for two to four weeks before removal; rollback is re-enabling the route.
3. Schema validation in report mode, then enforce: reject unknown properties, oversized payloads and undocumented routes per API once false positives are fixed.
4. Limits and flows: per-identity rate limits, page caps, timeouts, provider spending caps, then per-flow controls for the business flows you named.
5. Egress and integrations: allowlist outbound destinations for fetchers and webhooks and validate partner responses.

Small vs large: a small team with a handful of APIs can get most of the way with a managed gateway, an identity provider, schema validation and authorisation tests in the existing unit test suite. Organisations with hundreds of services need a central inventory, shared authorisation libraries or a policy engine, and runtime discovery to catch drift. Track monthly: share of APIs in traffic with an owner and a current OpenAPI document, share of object endpoints with cross-tenant tests, deprecated versions still receiving calls, 403 and 404 ratio outliers investigated, and median time to fix critical API findings. Commission testing against the list with the Web Application Security Testing Guide, and harden GraphQL endpoints with the GraphQL Security Guide.

Standards and references

• OWASP: API Security Top 10 2023
• OWASP: API Security Project
• OWASP: API Security Top 10 2023 Release Notes
• OWASP: API1:2023 Broken Object Level Authorization
• NIST: SP 800-228 Guidelines for API Protection for Cloud-Native Systems
• OWASP: Top 10:2025 Introduction
• OWASP: Application Security Verification Standard (ASVS)
• MITRE ATT&CK: T1190 Exploit Public-Facing Application

Related NHI Mgmt Group resources: API Security Guide · Broken Access Control Prevention Guide · SSRF Prevention Guide · GraphQL Security Guide · API Security Buyer's Guide