Notifications
Clear all
Topic starter
06/09/2026 5:18 pm
TL;DR: APIs now drive more than 83% of internet traffic, yet 57% of enterprises report API-related data breaches and 99% face API security issues annually, according to LEVO. The underlying problem is not the absence of tools but the mismatch between static and dynamic testing and the identity, workflow, and runtime context APIs actually require.
NHIMG editorial — based on content published by LEVO: the article on SAST, DAST, and API security testing
By the numbers:
- 57% of enterprises report API related data breaches in the past two years.
- 99%, rly all enterprises, 99%, experience API related security issues annually.
Questions worth separating out
Q: How should security teams test APIs that depend on tokens, scopes and roles?
A: They should build tests around the actual identities and entitlements that call the API, then validate whether each token can only perform the actions it is supposed to perform.
Q: Why do SAST and DAST still miss broken object-level authorisation?
A: Because BOLA depends on whether a caller is entitled to a specific object at a specific moment, not just whether code looks unsafe or a live request succeeds.
Q: What are the signs that API penetration testing is missing real risk?
A: If a programme only tests a supplied endpoint list, reports many alerts without proof of exploit, or misses undocumented APIs, it is probably under-covering the true attack surface.
Practitioner guidance
- Map API testing to real identity paths Inventory the service accounts, OAuth clients, API keys, and session types that actually reach production APIs, then tie each testing scope to those identities rather than to endpoint lists alone.
- Add workflow-aware test cases Prioritise multi-step business flows, object-bound actions, and delegated access paths where authorisation depends on request order, token state, or object ownership.
- Correlate findings with runtime discovery Use continuous API discovery and sensitive data mapping so SAST and DAST results can be validated against the current attack surface instead of stale specifications.
What's in the full article
LEVO's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanations of how the platform handles authentication across OAuth, JWT, API keys, and mutual TLS.
- Detailed breakdowns of the runtime discovery and documentation workflow used to map live API surfaces.
- Operational examples of how specific findings are tied to real requests, real identities, and real data paths.
- The vendor's full treatment of how API security testing fits into CI and CD workflows at implementation stage.
👉 Read LEVO's full analysis of SAST, DAST, and API security risk →
API security testing gaps: what IAM and AppSec teams are missing?
Explore further
06/09/2026 5:19 pm
Static and dynamic testing are necessary controls, but they are not identity governance for APIs. SAST and DAST tell teams different things about code and runtime exposure, but they do not model whether a service account, token, or delegated workflow should be allowed to reach a given object. That leaves a governance gap where security evidence exists, yet authorisation remains unproven. Practitioners should treat API security as an identity-and-policy problem, not only a testing problem.
A question worth separating out:
Q: Should organisations prioritise API discovery before deeper vulnerability testing?
A: Yes, when the estate is incomplete or fast-changing. If you cannot reliably identify all exposed APIs, deeper testing will understate risk because it will miss services that are live, reachable, and potentially sensitive but absent from the original scan plan.
👉 Read our full editorial: SAST and DAST miss runtime API risk without identity context
