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.
Editorial analysis by NHI Mgmt Group, based on content published by LEVO: “DAST vs SAST: When to use which for API Security”.
By the numbers:
- 57% of enterprises report API related data breaches in the past two years.
- 99% experience API related security issues annually.
Key questions
Q: What breaks when APIs are discovered without identity context?
A: Without identity context, teams can map routes but not control callers.
Q: Why do SAST and DAST miss API authorization flaws in practice?
A: SAST sees code before runtime, while DAST sees live behaviour without always understanding the full identity chain.
Q: How do teams know if API security testing is actually effective?
A: Look for coverage of realistic workflows, successful reuse of returned values, and findings that map to business operations instead of only parameter errors.
Practitioner guidance
- Map API tests to real identity paths Tie test coverage to authenticated users, service accounts, API keys, and delegated tokens so findings reflect actual access paths rather than anonymous probes.
- Prioritise runtime workflow coverage Build test cases around multi-step API sequences, role changes, and object transitions because many authorization flaws only appear across a full workflow.
- Validate endpoint discovery before scoring risk Confirm that your testing platform has a living API inventory from traffic, specifications, or configuration, or you will miss exposed surfaces entirely.
Bottom line: SAST and DAST still matter, but they cannot fully govern API security when authorisation depends on live identity and workflow context.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 5:19 pm
API security testing has become an identity problem as much as an application testing problem. When authorisation depends on tokens, delegated access, and workflow state, a scanner that cannot understand identity context will miss the real failure mode. This is where AppSec and IAM need the same evidence set, not separate ones. Practitioners should treat runtime identity context as part of the attack surface.
A few things that frame the scale:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: How do IAM and platform teams share responsibility for API security?
A: IAM teams should own entitlement model, lifecycle policy, and review standards, while platform teams enforce those decisions in gateways and service controls. The goal is not split accountability, but one operating model for machine access that both teams can measure and enforce consistently.
👉 Read our full editorial: SAST and DAST miss runtime API risk without identity context