Notifications
Clear all
Topic starter
02/08/2026 9:43 am
TL;DR: Legacy DAST tools miss modern attack surfaces because they depend on HTML crawling, session-style authentication, and stateless request testing, while API-first applications use SPAs, OAuth, JWTs, API keys, and multi-step workflows, according to StackHawk. The security gap is now architectural, not just tooling-related: if scanners cannot reach, authenticate to, and sequence through APIs, they cannot meaningfully test the application.
NHIMG editorial — based on content published by StackHawk: Why Legacy DAST Fails for Modern Applications and How to Fix It
Questions worth separating out
Q: How should security teams test API-first applications when crawling no longer works?
A: Use API-native testing that discovers endpoints from schemas or direct request mapping, then validates them with real authentication and stateful workflows.
Q: Why do API authentication methods create blind spots for legacy DAST?
A: Legacy DAST expects a browser-style session, but modern APIs often rely on OAuth, JWTs, API keys, or custom token flows.
Q: What breaks when security testing is stateless in API workflows?
A: Sequential logic breaks first.
Practitioner guidance
- Verify API-native discovery coverage Check whether your testing stack ingests OpenAPI, GraphQL, gRPC, or SOAP definitions directly instead of depending on HTML crawling.
- Test real authentication flows end to end Confirm that scanners can obtain and reuse OAuth tokens, JWTs, API keys, and custom auth sessions without manual workarounds.
- Require stateful workflow testing Build API tests that preserve context across multiple requests so business logic, replay conditions, and authorization changes are exercised in sequence.
What's in the full article
StackHawk's full blog covers the operational detail this post intentionally leaves for the source:
- How the vendor maps OpenAPI, GraphQL, gRPC, and SOAP schemas into test coverage for API routes.
- How its authentication handling works across OAuth, JWTs, API keys, and custom login flows.
- How stateful workflows are executed across sequential API calls to uncover logic flaws and authorization bypasses.
- How the CI/CD integration is intended to fit into developer workflows without changing the application architecture.
👉 Read StackHawk's analysis of why legacy DAST fails for modern API-first applications →
API-first applications: what legacy DAST still misses in practice?
Explore further
02/08/2026 12:36 pm
API-first security creates an authentication visibility gap: when scanners cannot obtain or carry the same credentials as legitimate clients, they are blind to the routes that matter most. That is not just a testing defect, it is a governance failure around machine access and authorisation state. Security teams should treat scanner authentication as part of the control surface, not a setup detail.
A question worth separating out:
Q: How should organisations govern scanner access to production-like APIs?
A: Treat scanner credentials as non-human identities with their own lifecycle, scope, and rotation requirements. Security tools often need broad enough access to test authenticated routes, but that access should still be time-bound, monitored, and revocable. If the scanner depends on stale or overly broad machine credentials, it weakens both testing reliability and access control.
👉 Read our full editorial: Legacy DAST fails for API-first apps because crawling no longer works
