TL;DR: OWASP API Top 10 compliance now depends on lifecycle evidence, not perimeter scans, because gateway logs rarely prove object-level authorization, authentication, or inventory coverage across design, pre-production, and runtime, according to AccuKnox. That shifts API security toward measurable controls, continuous discovery, and audit-ready test artefacts rather than one-time assessments.
At a glance
What this is: AccuKnox’s checklist says OWASP API Top 10 testing must prove control coverage with evidence, not rely on perimeter scans or logs alone.
Why it matters: For IAM, API, and security teams, the key issue is whether object-level authorization, authentication, and inventory controls can be demonstrated across the API lifecycle.
Context
API security testing fails when teams confuse perimeter visibility with control assurance. A gateway can show that traffic passed through a control point, but it cannot prove that object-level authorisation, authentication handling, inventory coverage, or abuse resistance actually held across the full API lifecycle. That gap is especially relevant when auditors expect evidence, not just a passing scan.
The practical issue is governance: API risk lives in design, pre-production, and runtime, so compliance evidence has to exist at each stage. For IAM and NHI practitioners, the intersection matters because machine-to-machine APIs often depend on tokens, service identities, and delegated trust that are only as strong as the tests and artefacts behind them.
The article’s starting point is typical for modern API programmes: the control problem is not whether APIs exist, but whether teams can prove they are constrained, inventoried, and tested consistently.
Key questions
Q: What breaks when API security testing only checks gateway-visible traffic?
A: Gateway-only testing misses the core failures that matter most: object-level authorization, function-level authorization, internal API versions, and business-flow abuse. A request can look clean at the perimeter while the service still returns another user’s data or accepts a privileged action. Effective testing has to prove server-side policy enforcement and lifecycle coverage.
Q: Why do OWASP API controls need evidence across design, pre-production, and runtime?
A: Because different failures appear at different stages. Design-time documents the intended control, pre-production proves the build can enforce it, and runtime shows the control still holds after deployment, inventory changes, and abuse attempts. If evidence exists in only one phase, the organisation cannot claim the API is governed end to end.
Q: What are the signs that API inventory management is failing in practice?
A: Common signs include endpoints that are reachable in production but missing from the inventory, documented APIs that no longer receive traffic, and versioned or deprecated APIs that remain accessible. Another warning is declining control coverage, where active APIs lack current logging, policy enforcement, or clear ownership. These symptoms show the inventory no longer reflects runtime reality.
Q: Should teams prioritise API1, API2, and API9 before deeper OWASP testing?
A: Yes. Those three risks define whether the organisation can trust who can reach an object, whether authentication is safe, and whether it even knows all the APIs in scope. Once those foundations are covered, teams can expand into property-level authorisation, function-level authorisation, misconfiguration, and third-party API risk.
Technical breakdown
Why gateway logs do not prove API security controls
Gateway logs and WAF alerts are perimeter signals. They show what reached the edge, but they do not prove that the API enforced authorisation on the object being requested, that a token was validated correctly, or that an internal endpoint was included in scope. OWASP API testing has to check the application behaviour itself, using valid identities and realistic requests. That is why a control can appear healthy from the outside while still failing on specific object types, legacy versions, or east-west paths. The evidence question is therefore about control behaviour, not traffic presence.
Practical implication: require request-response evidence from authenticated tests, not just gateway output, before claiming API control coverage.
Design, pre-production, and runtime each need different evidence
The checklist treats API security as a lifecycle discipline. Design-time evidence documents the intended control. Pre-production evidence shows the control works against a real build. Runtime evidence proves the control still holds after deployment, when inventory drifts, new endpoints appear, or abuse patterns emerge. This is why one-off scanning is insufficient for API9 inventory gaps or API6 business-flow abuse. The same risk can look resolved in CI/CD and fail later in production if the control is not continuously observed.
Practical implication: map every OWASP API risk to the lifecycle stage where you can prove it, and close any gap where proof is missing.
API1, API2, and API9 are the highest-leverage testing priorities
The article’s prioritisation is sensible because broken object-level authorisation, broken authentication, and improper inventory management are the control failures most likely to create broad exposure. API1 tests whether object access is actually constrained. API2 tests whether identities and tokens are being accepted safely. API9 tests whether you know all the APIs that exist, including old versions and east-west services. In NHI terms, these are governance tests for machine identities and service-to-service trust, not just application behaviour.
Practical implication: start with the three control areas that define exposure first, then expand to property-level authorisation, function-level authorisation, and misconfiguration.
Threat narrative
Attacker objective: The attacker’s objective is to use legitimate API access paths to obtain data or manipulate business flows that should have remained out of reach.
- Entry occurs when an authenticated user, token holder, or scripted client reaches an API endpoint that was assumed to be protected.
- Credential or request abuse follows when the attacker reuses valid authentication while probing object IDs, token handling, or undocumented endpoints.
- Escalation happens when broken object-level authorisation, broken authentication, or missing inventory lets the attacker move from a single request to broader access across objects or versions.
- Impact is unauthorised data access, business-flow abuse, or lateral movement through internal and east-west APIs that were never properly governed.
Breaches seen in the wild
- Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.
- McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
API compliance is now an evidence problem, not a scan problem. The article captures a broader shift in security governance: auditors and defenders increasingly need proof that controls work at the object, token, and workflow level. That makes synthetic tests, request-response pairs, and lifecycle artefacts central to assurance. For practitioners, the control question is no longer whether a tool detected traffic, but whether the organisation can prove the API behaved safely under test.
API inventory is becoming a trust boundary for machine identities. In modern environments, the APIs you forgot to inventory are often the ones that service accounts, tokens, and internal clients still reach. That creates a direct identity governance problem because untracked endpoints create untracked trust. The named concept here is API evidence debt: the gap between what exists, what is tested, and what can be proven to auditors. Teams should treat that debt as an exposure metric, not a documentation issue.
Object-level authorisation remains the hardest control to demonstrate because it is behavioural. A scan can confirm an endpoint exists, but only a context-aware test can show that one identity cannot reach another object’s data. This is why API1 is still a top-tier risk in breach analysis and audit work. For practitioners, the lesson is clear: if the control cannot be demonstrated with authenticated evidence, it is not yet governable at scale.
East-west API traffic is where governance assumptions often collapse. The article is right to call out internal service-to-service traffic because internal APIs are frequently less visible than public ones but just as sensitive. That is where service identities, delegated tokens, and weak inventory practices combine into hidden exposure. For teams running cloud-native and microservices estates, the implication is to govern internal APIs with the same discipline as internet-facing ones.
API security, IAM, and compliance are converging around the same proof standard. Once regulatory frameworks treat API controls as evidence-backed obligations, IAM teams can no longer separate identity assurance from application assurance. The practical result is tighter coupling between access control design, test automation, and audit artefacts. Practitioners should align API testing, service identity governance, and compliance evidence into one control narrative.
From our research library:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
- Read next: Ultimate Guide to NHIs — Standards
What this signals
API evidence debt: teams that cannot prove object-level authorisation, authentication, and inventory coverage are carrying an assurance gap that scans alone will not close. The more services and versions you run, the more that gap becomes a governance issue rather than a testing inconvenience, according to the 2024 State of Secrets Management Survey.
For practitioners, the operational shift is toward continuously proving control behaviour at design, pre-production, and runtime. That means internal APIs, east-west traffic, and service-to-service trust need the same inventory discipline as public endpoints, especially as third-party API use continues to expand.
The closer API security gets to identity governance, the less useful perimeter-only assurance becomes. Teams should expect auditors to ask for artefacts that show how the API behaved under valid credentials, not just how many requests the gateway observed.
For practitioners
- Build evidence for each API risk Map API1 through API10 to the exact artefacts that prove control operation, such as request-response pairs, policy exports, configuration snapshots, or runtime logs.
- Test authenticated access, not just endpoints Use real tokens and role variation to verify object-level and function-level authorisation across user types, object classes, and internal endpoints.
- Create an authoritative API inventory Track endpoint, version, owner, authentication method, and data classification, then compare discovery output against that inventory on a continuous basis.
- Cover east-west traffic explicitly Include internal service-to-service calls in testing and evidence collection so hidden APIs do not escape the same authorisation and inventory checks as public ones.
- Prioritise the highest-leverage OWASP risks Start with API1, API2, and API9, then extend to property-level authorisation, function-level authorisation, and security misconfiguration once the core exposure surface is controlled.
Key takeaways
- OWASP API compliance is moving toward evidence-based assurance, where test artefacts matter more than perimeter visibility alone.
- The highest-risk gaps are still broken object-level authorisation, broken authentication, and incomplete API inventory, especially across internal and legacy services.
- Teams that cannot prove control behaviour at design, pre-production, and runtime should treat API security as an inventory and identity-governance problem, not just a scan result.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | API1 is the core control tested throughout the checklist. |
| API2 — Broken Authentication | Broken authentication drives the need for token and login testing evidence. | |
| API9 — Improper Inventory Management | The article repeatedly stresses complete API inventory as a prerequisite for assurance. | |
| Recommendation — Test authenticated object access by role and object type, then retain request-response evidence for every denied or allowed case. Validate token handling, expiry, and login protections with realistic attack simulations and keep the results as evidence. Maintain a live inventory of every API version and endpoint, then reconcile it continuously against discovery output. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | API access control and entitlement proof map directly to CSF 2.0 authorisation governance. |
| Recommendation — Apply PR.AA-05 to verify that API permissions are explicit, tested, and evidenced across the lifecycle. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s threat model includes token abuse, internal API reach, and east-west movement. |
| Recommendation — Map API abuse paths to credential access and lateral movement, then prioritise tests for token misuse and internal service reach. | ||
Key terms
- API Evidence Debt: The gap between the controls an organisation believes it has and the proof it can actually produce for those controls. In API security, this debt appears when scans, logs, and policy documents do not demonstrate behaviour across design, pre-production, and runtime.
- Object Level Authorization: Object level authorization controls access to individual records or resources, not just to an endpoint. It prevents users from reaching data that is technically available through a route but should remain hidden according to policy, role, or ownership. This is a key safeguard against broken access control.
- API Inventory: An API inventory is the authoritative record of what interfaces exist, who owns them, what data they touch, and how they are authenticated. For identity governance, it is the baseline control that makes review, monitoring, offboarding, and risk prioritisation possible across distributed services.
- East-West API Traffic: API traffic that moves between internal services rather than between a client and a public edge. It is important because internal calls often bypass the scrutiny applied to internet-facing traffic while still carrying sensitive data and privileged machine identities.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security and compliance programmes they already run.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org