Should teams prioritise API1, API2, and API9 before deeper OWASP testing?

Why API1, API2, and API9 Come First

Yes, and the sequencing matters. API1, API2, and API9 are the tests that tell you whether the API estate is even knowable, whether callers are authenticated correctly, and whether object access is enforced at all. If those three are weak, deeper testing can produce a false sense of coverage because you are inspecting functions and properties on top of an unsafe access model.

API9 belongs early because inventory gaps create blind spots: you cannot test what you have not identified, and undocumented endpoints often become the easiest path for abuse. API2 should come next because broken authentication invalidates every later trust decision. API1 then checks whether authenticated users can reach objects they should not, which is the most basic authorisation failure pattern in API security.

That order is also practical for triage. A team that first confirms inventory, authentication, and object-level access can decide whether later findings are isolated defects or symptoms of a broader platform issue. OWASP API Security Top 10 is the clearest baseline for that prioritisation because it separates the most fundamental API failure modes from the deeper ones that come after them.

What Deeper OWASP Testing Adds After the Basics

Once API1, API2, and API9 are under control, deeper testing becomes much more valuable. API3 and API5 examine whether the API is leaking or protecting individual properties and functions with enough precision, while API8 checks whether configuration choices are undermining the security model. In other words, the early tests answer “can we trust the front door?”, and the later tests answer “can trusted users still misuse the rooms inside?”

That distinction matters because many real failures are not about missing code paths, but about overly broad exposure within otherwise legitimate access. Property-level and function-level flaws often appear only after an API is already authenticated and inventoried, which is why they are better treated as follow-on depth rather than the first priority. A structured verification standard such as OWASP ASVS helps teams turn that sequencing into testable requirements for authentication, access control, and verification depth.

Deeper testing also helps separate design failure from implementation drift. A team may have a sound intended model, yet still expose excess properties, weak object references, or misconfigured endpoints in a way that basic smoke tests will miss. That is why teams should move from “is the API generally secure?” to “which specific control failed, and at what layer of the request path?”

How to Sequence API Testing Without Missing the Real Risk

The best sequence is to treat the early OWASP API risks as gate checks, then expand outward. Start with inventory and authentication, then verify object-level access, then test property and function boundaries, then look for misconfiguration and third-party exposure. That approach reduces the chance of spending time on advanced findings before the organisation has proven it can reliably identify and protect the APIs that matter.

What to verify: Confirm that each API in scope is in the inventory, each authentication path is deliberate, and each object access decision is enforced server-side. If those conditions are not true, deeper testing should be paused until the foundations are fixed.

Decision rule: If you cannot reliably enumerate the API surface or prove authentication and object control, prioritise API1, API2, and API9 over more specialised checks. If those controls are stable, deeper testing should focus on whether specific properties, functions, and configurations can still be abused within the trusted boundary.

Practitioner takeaway: Teams get the most value when they use API1, API2, and API9 as the gate to deeper testing, not as a substitute for it. The goal is to earn confidence in the trust boundary first, then spend testing effort where residual exposure is most likely to hide.

Related resources from NHI Mgmt Group

• Should organisations prioritise API discovery before deeper vulnerability testing?
• Should teams prioritise ephemeral testing before broader test automation?
• Should organisations prioritise low-cost AI testing before deeper automation?
• How should security teams authenticate AI agents in enterprise environments?