Teams often pick one OWASP list for every application, which leaves API-only flaws untested in their mobile back ends and leaves browser and supply chain risks unchecked in their APIs. The OWASP Top 10:2025 and the OWASP API Security Top 10 2023 overlap on paper, but they were built differently, describe risk at different levels, and point testers at different behaviour. This guide compares the two lists on scope, method, overlap and testing approach, sets out the controls each one drives, and gives a decision method for applications that are part web front end and part API. It is for application security leads, penetration test buyers and architects who write testing requirements and need to say which list applies to which system. For category detail, see the OWASP Top 10 Guide and the Top 10 API Security Risks; this page does not repeat them.
Key takeaways
- The short answer is usually both. Use the web list for anything a browser renders and for platform risks such as supply chain and cryptography; use the API list for every endpoint a client calls with an object ID, a token or a business action.
- They were built in different ways. The 2025 web list is data informed, drawn from contributed testing data on more than 2.8 million applications plus a community survey; the API list is ranked by expert consensus using the OWASP Risk Rating Methodology.
- The API list splits what the web list lumps together. A01:2025 Broken Access Control covers ground that the API list divides into API1 object level, API3 property level and API5 function level authorisation.
- Each list has risks the other does not name. Only the API list calls out resource consumption, sensitive business flows, inventory and unsafe consumption of third-party APIs; only the web list calls out supply chain, cryptographic, integrity, logging and exceptional condition failures.
- Neither list is a test standard. Turn both into verifiable requirements with OWASP ASVS 5.0, and test them with methods that suit each risk, not with a single scanner profile.
Short answer: which list for which application
Classify the system by its attack surface, not by the team that owns it. Most modern products have a browser front end calling a JSON API, so they need both lists, with the API list driving most of the access control testing.
| System type | Lead list | Second list | Why |
|---|---|---|---|
| Server-rendered web application with forms and sessions | OWASP Top 10:2025 | API list only for any AJAX or integration endpoints | Browser behaviour, sessions, injection and configuration dominate |
| Single-page application calling a REST or GraphQL back end | API Security Top 10 2023 for the back end | OWASP Top 10:2025 for the front end, build chain and hosting | Authorisation decisions live in the API; the browser holds the client logic |
| Mobile app back end | API Security Top 10 2023 | OWASP Top 10:2025 for platform and supply chain; OWASP MASVS for the app | Clients are untrusted and call object IDs directly |
| Partner or public API product | API Security Top 10 2023 | OWASP Top 10:2025 for developer portal and hosting | Inventory, versioning, quotas and business flows carry the risk |
| Internal microservices and service-to-service calls | API Security Top 10 2023 | OWASP Top 10:2025 A03 and A08 for build and deployment | Machine callers, SSRF paths and unsafe consumption between services |
| Application built on a large language model | OWASP Top 10 for LLM Applications 2025 | Both of the above for the surrounding web and API layers | Prompt and model risks are outside both general lists |
For model and agent risks, see the OWASP Top 10 for LLM Applications Guide.
How each list is built, and why it matters
OWASP Top 10:2025
OWASP describes the Top 10 as a standard awareness document for developers and web application security, representing broad consensus on the most critical risks to web applications. The 2025 introduction calls the list data informed but not blindly data driven: eight categories come from contributed testing data and two from a community survey. Contributors supplied data on more than 2.8 million applications covering 589 CWEs, and the ten categories group 248 of them, capped at 40 per category. Exploit and impact weighting came from roughly 175,000 NVD CVE records mapped to CWEs. OWASP notes the data reflects past findings and can miss newer risks.
Consequence for practitioners: the categories are root cause groupings. A01 Broken Access Control, for example, holds 40 CWEs ranging from path traversal to cross-site request forgery and, since 2025, server-side request forgery. That breadth suits awareness and secure coding training, but a test plan built straight from a category name is vague.
OWASP API Security Top 10 2023
The API project's foreword says APIs expose application logic and sensitive data, and that their particular nature requires a separate list even though the web Top 10 still applies. Its methodology page states the edition is not data driven: prevalence came from consensus among the project team, scored with the OWASP Risk Rating Methodology on exploitability, prevalence, detectability and technical impact, with business impact left to each organisation.
Consequence for practitioners: the API list describes behaviours, not CWE families. API1 Broken Object Level Authorization tells a tester exactly what to try: change an object ID and see whether the server returns someone else's record. OWASP rates API6, API9 and API10 Average for detectability and the rest Easy, a hint about where automated tools struggle.
| Dimension | OWASP Top 10:2025 | OWASP API Security Top 10 2023 |
|---|---|---|
| Target | Web applications | APIs of any style: REST, GraphQL, RPC |
| Basis | Contributed testing data plus a community survey (two categories) | Project team consensus using the OWASP Risk Rating Methodology |
| Unit of risk | Root cause category grouping many CWEs | Specific API behaviour with an attack scenario |
| Previous edition | 2021 | 2019 |
| Strongest use | Developer awareness, secure coding training, platform risk | API design review, authorisation test cases, API programme scope |
| Weakest use | Writing precise test cases for API access control | Covering browser, build chain and cryptography risks |
Where the lists overlap and where they diverge
The mapping below shows the closest relationship between items. It is an NHI Mgmt Group interpretation, not an official OWASP crosswalk, and the Top 10 API Security Risks Guide carries the ASVS and CWE detail per item.
| Area | OWASP Top 10:2025 | API Security Top 10 2023 | Practical difference |
|---|---|---|---|
| Authorisation | A01 Broken Access Control | API1 BOLA, API3 BOPLA, API5 BFLA | API list separates object, field and function checks, each with its own test |
| Authentication | A07 Authentication Failures | API2 Broken Authentication | API list focuses on tokens, API keys and credential stuffing against login endpoints |
| SSRF | Inside A01 since 2025 | API7 Server Side Request Forgery | Same flaw; API list keeps it visible as its own item |
| Misconfiguration | A02 Security Misconfiguration | API8 Security Misconfiguration | API list adds CORS, verbose errors and missing transport security on API hosts |
| Injection | A05 Injection | Mainly through API10 Unsafe Consumption of APIs | API list treats injection mostly as data arriving from upstream APIs |
| Design and abuse | A06 Insecure Design | API6 Unrestricted Access to Sensitive Business Flows | API list names automated abuse of legitimate flows such as checkout and sign-up |
| Availability and cost | No direct category | API4 Unrestricted Resource Consumption | Rate limits, pagination, payload size and paid third-party calls |
| Inventory | No direct category | API9 Improper Inventory Management | Old versions, undocumented hosts and data flows to partners |
| Supply chain | A03 Software Supply Chain Failures | No direct item | Dependencies, build systems and distribution |
| Cryptography | A04 Cryptographic Failures | No direct item (transport touched in API8) | Key management and algorithm choice |
| Integrity | A08 Software or Data Integrity Failures | No direct item | Deserialisation, unsigned updates and pipelines |
| Logging | A09 Security Logging and Alerting Failures | No direct item in 2023 | Detection must be added to API programmes deliberately |
| Error handling | A10 Mishandling of Exceptional Conditions | Partly API8 (verbose errors) | Fail-open logic and unhandled states |
Two gaps catch API programmes out. First, the 2023 API list has no logging item, so an API team that only tracks the API list can ship endpoints with no abuse detection. Second, it has no supply chain item, yet API gateways, SDKs and code generators are all dependencies. Pull A03, A08 and A09 from the web list into every API scope. The T-Mobile API Breach 2023: How One Abused API Leaked Data on 37 Million Accounts shows the detection point: the company reported that a single API was abused from around 25 November 2022 and the activity was detected on 5 January 2023.
Testing approach per list
The lists suggest different testers, different inputs and different evidence.
| Risk area | Best primary method | What the tester needs | Evidence to ask for |
|---|---|---|---|
| API1, API3, API5 authorisation | Authorisation tests with two or more users per role, manual testing, automated replay with swapped tokens | Accounts in at least two tenants and two roles; API specification | Request pairs showing user B reading or changing user A's object or field |
| API2 and A07 authentication | Configuration review plus targeted testing of login, token and reset flows | Token formats, identity provider settings | Token lifetime, signature validation and lockout results |
| API4 resource consumption, API6 business flows | Threat modelling and manual abuse case testing in a safe environment | Rate limit design, list of sensitive flows, cost of downstream calls | Documented limits per endpoint and the result of exceeding them |
| API9 inventory | Discovery from gateway logs, DNS and traffic, reconciled with specifications | Access to gateway, cloud and repository data | Inventory with owner, version, environment and data classification |
| A05 injection, A02 and API8 misconfiguration | DAST and SAST, then manual confirmation | Running build, specification for API scanning, source for SAST | Confirmed findings with request and response, false positives closed |
| A03 supply chain, A08 integrity | Software composition analysis, build pipeline review | Repository, lockfiles, build configuration | Software bill of materials and pipeline control evidence |
| A09 logging | Detection testing: run test cases and confirm alerts fire | Access to the SIEM or log platform | Alert records for each simulated abuse case |
OWASP's API DevSecOps guidance makes the same point about cadence: it says scanning and penetration testing yearly are no longer enough, recommends basing test priorities on a threat model, and suggests using ASVS and the OWASP Testing Guide where none exists. The OWASP WSTG Guide covers the web testing method; the stable WSTG release is v4.2, with v5.0 in development on the project page as of November 2026. For API test design, use the API Security Testing Plan Template and see the API Penetration Testing Guide.
Controls each list drives
Controls the web list drives
- Central access control: deny by default and enforce on the server, which A01 groups with path traversal and CSRF protections. See the OWASP Top 10 A01 Guide.
- Hardened, repeatable configuration: security headers, disabled defaults and environment parity for A02.
- Supply chain controls: dependency inventory, pinned versions and protected build systems for A03. See the OWASP Top 10 A03 Guide.
- Output encoding and parameterised queries: the baseline for A05 Injection.
- Logging and alerting that someone acts on: A09 asks for alerts, not just log retention.
- Fail-closed error handling: A10 covers unhandled exceptions and logic that grants access when a check errors. See the OWASP Top 10 A10 Guide.
Controls the API list drives
- Per-object authorisation in code: every handler that receives an object ID checks the caller's right to that object. ASVS 5.0 requirement 8.2.2 states this for IDOR and BOLA, 8.2.3 for field level access (BOPLA) and 8.2.1 for function level access. See the BOLA vs BFLA guide.
- Response shaping: return explicit field allowlists rather than serialised objects, which closes excessive data exposure and mass assignment under API3.
- Limits per endpoint and per client: rate, pagination, payload size and cost limits for API4, and anti-automation for API6, which ASVS 2.4.1 describes. For GraphQL, ASVS 4.3.1 asks for query allowlists, depth limiting or cost analysis. See the Rate Limiting and API Abuse Guide.
- Outbound request controls: allowlisted destinations and blocked metadata endpoints for API7. See the OWASP API Top 10 API7 Server-Side Request Forgery Guide.
- Inventory and retirement: an owned record for every host, version and environment, with deprecated versions removed, for API9. See the OWASP API Top 10 API9 Improper Inventory Management Guide and the API Inventory Template.
- Treat upstream APIs as untrusted: validate data received from partners and limit redirects for API10.
Where identity fits
API2 is where the two lists diverge most on identity. The web list's A07 is mostly about human sign-in: credential stuffing, weak passwords and session fixation. In APIs, most callers are machines holding API keys, OAuth client credentials or service tokens, and A07 language does not prompt a reviewer to check key scope, token audience or rotation. Add these checks explicitly to API2 testing: which non-human identities call the API, what each one can reach, how keys are issued and revoked, and whether tokens are validated for audience and expiry at every service, not only at the gateway. Authorisation tests also need dedicated test accounts in several roles and tenants; govern them like any other identity. See the Test and Synthetic Accounts Governance Guide.
Worked scenarios
Scenario 1: retail single-page application. A React storefront calls a REST API for basket, orders and account data. The team had used the web Top 10 as its penetration test scope, and reports showed headers and XSS findings but nothing on orders. Rescoped, the API list drives the back end: two customer accounts test API1 on order IDs, the checkout and voucher flows are tested under API6, and the order search endpoint is checked for API4 pagination limits. The web list stays for the front end, the content delivery configuration and A03 on the JavaScript dependency tree.
Scenario 2: partner API platform. A logistics firm exposes v1, v2 and v3 of a shipment API to partners. A penetration test of v3 finds little, but discovery from gateway logs shows v1 still answering on an old host without the newer authorisation checks. API9 becomes the lead risk: build the inventory, retire v1, and add A09 alerting on calls to deprecated paths.
Scenario 3: internal microservices. A bank's payment services call each other with service tokens and fetch exchange rates from a third-party API. API7 and API10 lead: outbound calls are allowlisted, rate data is validated before use, and each service checks token audience. A08 from the web list covers signed container images and pipeline integrity, because a compromised build would bypass every runtime control.
Decision guidance by organisation size
- Small teams with one product: write one combined scope. List the API items for the back end and the web items for the front end and platform, and test authorisation manually with two accounts per role before buying any API-specific tool.
- Mid-sized organisations: map each application to a testing tier and state which list applies to which component. Feed both into one set of ASVS-based requirements so developers see one standard. See the Application Security Requirements from ASVS template.
- Large or API-first organisations: run the API list as a programme, not a test scope: inventory, design review, gateway policy and runtime monitoring, with the web list owned by front end and platform teams. NIST SP 800-228 organises API controls into pre-runtime and runtime stages; its March 2026 update adds an appendix of API risks by category and one of controls by lifecycle stage.
How to implement a two-list programme
- Inventory first: list every application and every API host, version and environment, with an owner. Without this, API9 is already failing.
- Classify components: mark each component as browser front end, API, both, or LLM-based, and assign lead and second lists using the table above.
- Translate to requirements: convert the relevant items into ASVS 5.0 requirements at the level that matches the application's risk. See the OWASP ASVS Guide.
- Pilot on one product: run the combined scope on a single API-backed application, with authorisation test accounts provisioned in a non-production tenant, and compare findings with the previous web-only scope.
- Automate what is detectable: put injection, misconfiguration and dependency checks into the pipeline; keep authorisation and business flow testing as scheduled manual work with automated regression for fixed issues.
- Add detection: define alerts for repeated object ID enumeration, calls to deprecated versions and rate limit breaches, and test that they fire.
- Roll out and review: extend to other products by tier. If a new scope floods teams with unconfirmed findings, roll back to the previous scope for that product while triage rules are fixed.
Detection and measurement
- Scope coverage: percentage of API-backed applications whose test scope includes API1, API3 and API5 authorisation testing with multiple accounts.
- Inventory accuracy: share of API hosts seen in gateway or traffic logs that appear in the inventory with an owner.
- Authorisation escape rate: access control flaws found in production or by external researchers compared with those found in testing.
- Deprecated version exposure: number of retired API versions still answering requests.
- Alert validation: proportion of defined abuse cases (enumeration, rate breaches, deprecated calls) that produced an alert during testing.
Log object access decisions with caller identity, object ID and result, so enumeration patterns can be detected. ASVS 5.0 requirement 16.3.1 asks that all authentication operations are logged, successful and unsuccessful.
Common failure patterns
- Web-only scope for API products: the test report covers headers and XSS while order, invoice or profile IDs are never swapped between users.
- Treating the API list as a scanner profile: API6 and API9 are rated Average for detectability by OWASP and depend on business context and inventory, not payloads.
- Single test account: without accounts in two tenants and two roles, BOLA and BFLA cannot be shown at all.
- No logging requirement for APIs: because the 2023 API list has no logging item, teams omit detection, and abuse runs for weeks.
- Ignoring old versions: testing only the current API version while earlier versions remain reachable on legacy hosts.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-3 Access Enforcement, AC-6 Least Privilege | API1, API3, API5 and A01 authorisation controls |
| NIST SP 800-53 Rev. 5 | SC-5 Denial-of-service Protection | API4 resource limits |
| NIST SP 800-53 Rev. 5 | SI-10 Information Input Validation | A05 injection and API10 upstream data |
| NIST SP 800-53 Rev. 5 | CM-8 System Component Inventory | API9 inventory |
| NIST SP 800-53 Rev. 5 | SA-11 Developer Testing and Evaluation, CA-8 Penetration Testing | Testing against both lists |
| NIST CSF 2.0 | PR.PS-06, ID.RA-01, DE.CM-09 | Secure development, vulnerability identification, runtime monitoring |
| OWASP ASVS 5.0 | V8 Authorization, V4 API and Web Service, V2 Validation and Business Logic, V16 Security Logging and Error Handling | Verifiable requirements for both lists |
| MITRE ATT&CK | T1190 Exploit Public-Facing Application | Initial access through flaws in either list |
Practitioner checklist
- Classify every component as front end, API, both or LLM-based, and record the lead and second OWASP list.
- Include API1, API3 and API5 tests with accounts in at least two tenants and two roles for every API-backed application.
- Pull A03, A08 and A09 from the web list into every API scope.
- Pull API4, API6 and API9 into the scope of any web application with a JSON back end.
- Maintain an API inventory with owner, version, environment and data classification, and retire old versions.
- Express requirements in ASVS 5.0 rather than citing list item names in contracts.
- Define and test alerts for enumeration, rate breaches and deprecated version calls.
- Govern scanner and test accounts as non-human identities with least privilege and rotation.
Standards and references
- OWASP: Top 10:2025
- OWASP: Top 10:2025 Introduction and Methodology
- OWASP: API Security Top 10 2023
- OWASP: API Security Risks, Risk Rating Methodology
- OWASP: API Security Top 10, What's Next for DevSecOps
- OWASP: Application Security Verification Standard 5.0
- OWASP: Web Security Testing Guide
- NIST: SP 800-228 Guidelines for API Protection for Cloud-Native Systems
Related NHI Mgmt Group resources: API Security Guide · OWASP API Top 10 API8 Security Misconfiguration Guide · Shadow APIs vs Zombie APIs · GraphQL Security Guide · Penetration Testing vs DAST