Topic starter
06/09/2026 9:34 am
TL;DR: Most API security failures arise from valid requests doing unintended things, not from missing authentication, according to LEVO. The real control gap is runtime enforcement of authorization, data exposure, and shadow API visibility, because boundary tools cannot see how an API behaves once the request is accepted.
Editorial analysis by NHI Mgmt Group, based on content published by LEVO: “API Security Best Practices for Enterprises (2026 Guide)”.
Key questions
Q: What breaks when API authentication is correct but authorisation is weak?
A: Attackers can still read or modify data they should not reach, because identity was proven without proving entitlement.
Q: Why do valid API requests still create breach risk?
A: Valid API requests still create breach risk because authentication proves the caller is known, not that the caller is entitled to the specific object.
Q: How can security teams tell whether API risk controls are actually working?
A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why.
Practitioner guidance
- Map every API to an owner and data class Inventory documented, undocumented, internal, and deprecated APIs, then assign ownership and sensitivity labels so no interface sits outside governance.
- Enforce action-level authorization Apply authorization checks to the specific record, object, or workflow step being requested, not just to the endpoint or authenticated session.
- Minimise response payloads by default Remove unused fields, mask sensitive values, and prevent internal object structures from being returned simply because the caller is authenticated.
Bottom line: Most API breaches are governance failures at runtime, where valid access is allowed to do more than the business intended.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 9:34 am
Runtime API security is now a governance problem, not just a traffic-filtering problem. The article is right to move attention away from authentication alone because modern APIs are judged by what they allow after access is granted. That makes authorization scope, response design, and behavioural policy the real control surface. For IAM and NHI teams, the practical conclusion is that identity assurance must be matched by runtime constraint.
A few things that frame the scale:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: When should organisations prioritise API discovery over more perimeter filtering?
A: When the API landscape is changing faster than the inventory, discovery should come first because you cannot govern what you cannot see. Perimeter filtering helps only after the active and shadow surfaces are known. For organisations with many service integrations or AI-connected workflows, inventory completeness is the prerequisite for any durable control model.
👉 Read our full editorial: Runtime API security is about misuse, not just authentication