Topic starter
06/09/2026 5:18 pm
TL;DR: DAST tools simulate live attacks to uncover runtime vulnerabilities in web apps and APIs, but legacy scanners often miss business logic flaws, broken authorisation, and dynamic authentication paths, according to LEVO. The gap is no longer just coverage, but whether application testing can keep pace with how APIs actually behave in production.
Editorial analysis by NHI Mgmt Group, based on content published by LEVO: “Top 10 DAST Tools”.
By the numbers:
- Over 70% of successful breaches in 2023 stemmed from vulnerabilities in application layer components, especially APIs and web services.
Key questions
Q: Why do legacy DAST tools miss broken authorisation in APIs?
A: Legacy tools often rely on static schemas, limited crawling, and isolated requests.
Q: How do teams know whether API testing is actually covering business logic risk?
A: Look for evidence that the testing can change user context, sequence calls, and verify whether ownership and function-level checks are enforced across endpoints.
Q: What are the signs that API testing is not covering production reality?
A: The biggest warning signs are incomplete endpoint discovery, heavy dependence on manual schema uploads, fragile authentication setup, and scan results that look clean even though the API estate changes frequently.
Practitioner guidance
- Map API testing to real authorization paths Ensure DAST exercises role changes, token changes, and object-level access decisions rather than only probing public endpoints.
- Inventory hidden and undocumented APIs Use discovery processes that identify orphaned, partner, and backend service APIs so they are not excluded from security validation.
- Validate OAuth and JWT flows under runtime conditions Test short-lived tokens, chained authentication, and service-account access in environments that mirror production behaviour.
Bottom line: Legacy DAST can still catch runtime flaws, but it is not enough on its own for modern APIs where authorization depends on state, identity, and workflow.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 5:19 pm
Runtime testing has become an identity and authorization control, not just an AppSec control: when APIs depend on tokens, delegated access, and role-sensitive workflows, the testing question is whether those runtime decisions behave as intended. A scan that cannot observe live authorization paths is not validating access governance, only endpoint reachability. Practitioners should treat runtime API testing as part of entitlement assurance.
A question worth separating out:
Q: Should security teams prioritise runtime API testing over generic web scanning?
A: They should prioritise runtime API testing where business logic, delegated access, or service-to-service authorisation drives risk. Generic web scanning still has value for traditional input flaws, but it cannot replace identity-aware validation for modern API estates. The right balance is both, with the runtime view given more weight when APIs carry sensitive access.
👉 Read our full editorial: Legacy DAST tools miss API runtime flaws that attackers exploit