Notifications
Clear all
Topic starter
06/09/2026 5:18 pm
TL;DR: DAST still catches runtime issues in live applications, but LEVO argues it falls short for API first enterprises because it cannot reliably see internal APIs, authentication flows, or business logic risks such as BOLA and shadow APIs. The practical takeaway is that API discovery, context-aware testing, and runtime visibility now need to sit alongside traditional AppSec controls.
NHIMG editorial — based on content published by LEVO: DAST for API security: what it can and cannot solve in an API first enterprise
By the numbers:
- API attacks have risen more than 400% year over year.
- Over 90% of organisations using APIs experienced at least one API security incident in a single year.
- 80% of exposures in a study of more than 40 million security exposures were caused by misconfigurations, not flawed code.
Questions worth separating out
Q: How should security teams test APIs when DAST cannot see internal workflows?
A: Use DAST for what it does well, which is validating externally reachable runtime behaviour, then add traffic-based discovery, schema-aware testing, and identity-aware authorisation checks.
Q: Why do APIs create so much risk in modern web applications?
A: APIs often carry the real business logic of an application, including data access, account actions, and administrative functions.
A: Common warning signs are heavy manual configuration, repeated false positives, incomplete coverage, and low team usage after rollout.
Practitioner guidance
- Expand API discovery beyond crawlable endpoints Build continuous discovery from traffic, gateway logs, and service telemetry so internal, low-traffic, and shadow APIs enter the test scope.
- Test authorisation at the object and workflow level Validate BOLA, token scope, and multi-step business logic separately from generic runtime vulnerability checks, especially where service identities move between systems.
- Correlate runtime findings with identity context Tie each DAST finding to the authenticated principal, token type, and service account involved so teams can distinguish exposure from legitimate access.
What's in the full article
LEVO's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step API security testing workflow guidance for environments where authentication and discovery are changing daily.
- Comparative product discussion of DAST alternatives for teams evaluating runtime visibility, discovery, and workflow-aware testing.
- Implementation detail on how the platform maps sensitive data, runtime behaviour, and API inventory across the SDLC.
- The vendor's own breakdown of where legacy AppSec tools fit, and where they stop being sufficient.
👉 Read LEVO's analysis of why DAST falls short for API first security →
DAST and API security gaps: what IAM teams need to know?
Explore further
06/09/2026 5:19 pm
DAST coverage breaks down when identity becomes the control plane. The article makes the structural issue clear: modern APIs are not just endpoints, they are access decisions wrapped in transport. When tokens, service accounts, and delegated permissions determine access, crawler-based testing sees only part of the control story. That is an IAM and NHI governance problem as much as an AppSec one, because the real risk sits in how identity is asserted and consumed across services.
A question worth separating out:
Q: Should organisations treat DAST and API security as the same control?
A: No. DAST is a runtime testing method, while API security is a broader governance problem covering discovery, authorisation, identity context, and monitoring. DAST can support the programme, but it cannot replace continuous visibility or control over who and what is allowed to access data and actions across the API estate.
👉 Read our full editorial: DAST is not enough for API first security governance
