Topic starter
02/08/2026 9:43 am
TL;DR: Single-page applications break the assumptions behind traditional DAST because client-side JavaScript changes the DOM while backend APIs remain the real attack surface, and StackHawk says that approach can miss more than 90% of API routes. The governance shift is from scanning the front end to testing the API specification and runtime paths developers actually expose.
Editorial analysis by NHI Mgmt Group, based on content published by StackHawk: “Single Page Application Security Testing: Is Scanning Your SPA with DAST Wrong?”.
By the numbers:
- Traditional scanners typically find less than 10% of the API attack surface when crawling SPAs.
Key questions
Q: What breaks when DAST is used as the only API security test?
A: DAST misses flaws that depend on application meaning, especially broken object level authorization and multi-step business logic abuse.
Q: Why do SPA back ends need direct API testing instead of browser simulation?
A: Browser simulation only approximates user behaviour, while direct API testing exercises the service interface that actually enforces authentication, authorisation, and input validation.
Q: What are the signs that SPA security testing is missing the real risk?
A: Common signs include very low route coverage, long scan times, inconsistent findings across repeated runs, and reports that focus on front-end activity while backend endpoints remain under-tested.
Practitioner guidance
- Adopt API-first security testing for SPAs Use API specifications, Postman collections, or engineering test suites as the primary scan input so security coverage starts with the backend services rather than the front-end DOM.
- Measure coverage against the real attack surface Track how many discovered endpoints, methods, and parameters are actually exercised by testing, then compare that against the full API catalogue exposed by the application.
- Separate front-end checks from backend verification Keep browser-based checks for UI behaviour, but require direct API testing for authorisation, input handling, and route coverage.
Bottom line: SPAs expose backend APIs as the real security boundary, so front-end crawling alone cannot provide reliable coverage.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:36 pm
SPA testing is really API governance in disguise: the security question is not whether the browser can be crawled, but whether the organisation can reliably discover and exercise the backend services the SPA depends on. When discovery starts at the user interface, coverage becomes a by-product of browser behaviour instead of an explicit control objective. Practitioners should treat API inventory and testability as a governance requirement, not a tooling preference.
A question worth separating out:
Q: How should security teams coordinate with developers on SPA testing?
A: Teams should use shared artefacts such as OpenAPI specifications or engineering-owned test suites so security testing aligns with the application’s actual design. That reduces guesswork, improves coverage, and gives developers faster feedback on the controls that matter at the API boundary. The key is to make testability part of the delivery workflow.
👉 Read our full editorial: Single-page application DAST is missing the real API attack surface