Notifications
Clear all
Topic starter
02/08/2026 9:43 am
TL;DR: Traditional DAST scanners struggle with single-page applications because client-side JavaScript keeps the DOM changing and leaves most backend API routes undiscovered, with the article saying coverage can fall below 10% of the API attack surface. The practical conclusion is that API-first testing and developer-owned specifications are now the governance baseline for modern web apps.
NHIMG editorial — based on content published by StackHawk: Single Page Application Security Testing: Is Scanning Your SPA with DAST Wrong?
By the numbers:
- The article says traditional SPA crawling can find less than 10% of the API attack surface.
Questions worth separating out
Q: How should security teams test single-page applications without relying on browser crawling?
A: They should treat the SPA as a presentation layer and test the underlying APIs directly.
Q: Why do SPAs create blind spots for traditional DAST tools?
A: SPAs change the DOM dynamically and often hide or generate routes after user actions, so crawl-based scanners cannot reliably enumerate the full application.
Q: What do security teams get wrong about SPA scanning?
A: They often assume that a successful front-end crawl means adequate application coverage.
Practitioner guidance
- Inventory APIs before you test them Create a living list of API domains, routes, methods, and auth requirements so DAST coverage can be measured against the full service surface rather than against browser-discovered pages.
- Use OpenAPI or test collections as the test source of truth Drive scans from OpenAPI specifications or engineering-built collections such as Postman so the security workflow covers parameters, verbs, and alternate request paths that a SPA crawler will miss.
- Validate authorisation at the endpoint level Test object-level and function-level access controls directly against APIs, because front-end navigation does not prove that a user or token is authorised for the underlying action.
What's in the full article
StackHawk's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on why SPA crawling fails and how direct API testing changes coverage outcomes.
- Examples of using OpenAPI specifications and Postman collections to drive repeatable security tests.
- Explanation of local scanning behind the firewall and why it improves speed and endpoint reach.
- Developer and security collaboration patterns for embedding API security testing into the SDLC.
👉 Read StackHawk's analysis of SPA security testing and API coverage →
SPA DAST scanning: are your controls keeping up with API risk?
Explore further
02/08/2026 12:36 pm
SPA scanning failure is really an API discovery problem: the security gap is not that the scanner is slow, it is that the scanner is looking in the wrong place. In modern web architectures, the front end is a moving façade while the API contains the enforceable access decisions. That means missing routes, parameters, or alternate methods is a coverage failure, not a tuning issue. Practitioners should treat this as a test-design problem, not a tool-speed problem.
A question worth separating out:
Q: How can security and development teams improve API security testing for SPAs?
A: They should share ownership of API artefacts such as OpenAPI specs, Postman collections, and test data so scanning can be aligned with how the application is built. That collaboration turns security testing into a repeatable part of the SDLC and improves the quality of findings before release.
👉 Read our full editorial: Single-page application DAST is missing the real API attack surface
