They should treat that gap as incomplete coverage and change the testing method, not the risk tolerance. Move to tools and workflows that can navigate dynamic flows, maintain session context and observe rendered states. Otherwise, the programme can report passing results while leaving important client-side and API-linked issues untested.
When a scanner cannot follow asynchronous SPA behaviour, what is the real problem?
The issue is not that the application is safe, it is that the scanner cannot exercise the same client-side paths a user or attacker can. Asynchronous single-page applications often change state through JavaScript, background requests and delayed rendering, so a passive or crawl-only tool may miss important views, inputs and API calls. That creates blind spots in coverage, not a reduction in risk.
For security testing, this usually means the tool is measuring an incomplete surface. A scanner that cannot wait for rendered content, follow dynamic navigation or preserve session state can easily report a clean result while never reaching the code paths that matter most. The correct response is to change the testing approach so it matches the application’s runtime behaviour.
What changes in testing when the app depends on dynamic client-side flows?
The test method needs to account for stateful interaction. That means using tools and workflows that can execute JavaScript, maintain cookies or tokens across steps, observe rendered DOM states and follow multi-step workflows that only appear after user actions. For APIs behind the SPA, testing must also recognise that the browser front end and the backend service surface are separate but connected attack paths.
This is especially important when validation, authorisation or business logic is only enforced after a client-side transition. If the scanner stops at the first page load, it may never reach the request that carries the real security decision. In practice, teams should prefer tooling that can traverse authenticated journeys, capture asynchronous requests and confirm the actual server responses, not just static page markup.
That is why browser-based scanning, recorded flows and manual or semi-automated verification remain important for SPAs. They let testers inspect both the UI state and the hidden requests that the interface triggers, which is where many client-side access and data-handling issues surface.
How should organisations respond to gaps in scanner coverage?
The right response is to treat the gap as a testing coverage problem and close it deliberately. If a scanner cannot see the flow, the programme should add another control point, such as authenticated browser-driven checks, targeted API testing or manual exploration of the dynamic path. Coverage should be redefined around observable application behaviour, not around what the original scanner was able to index.
Teams should also document which journeys are not being exercised automatically. That creates a clearer boundary between “tested and passed” and “untested because the tool could not reach it.” For SPAs, that distinction matters because client-side richness often increases the chance of hidden state transitions, inconsistent authorisation checks and missed injection or data-exposure issues.
Risk and Threat Considerations
When asynchronous behaviour is invisible to the scanner, organisations can get a false sense of assurance. The main risk is untested client-side and API-linked paths that appear absent in reports but still exist in production, especially in authenticated workflows where the dangerous request only appears after several state changes.
Failure mechanism: The scanner cannot execute the same sequence of asynchronous events, so it never reaches the rendered state or backend call where the weakness exists. That leaves coverage gaps in authorisation, input handling, data exposure and workflow integrity.
Impact: Vulnerabilities may remain undetected until exploitation or incident review, and the security programme may overstate its assurance because the missing paths were never exercised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | SPA flows often hide backend API calls that need security verification. |
| V16 — Security Logging and Error Handling | Dynamic flows need observable states and evidence when scanners miss paths. | |
| V15 — Secure Coding and Architecture | Client-side state transitions change how the application should be assessed. | |
| Recommendation — Test authenticated API-driven workflows behind the SPA, not just the rendered UI. Capture request and response evidence for asynchronous journeys that scanners cannot fully exercise. Use browser-driven and workflow-aware testing for SPA paths that static scanning cannot reach. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Unseen SPA calls can leave API surfaces untested and effectively untracked. |
| Recommendation — Inventory the backend endpoints that SPA flows invoke and include them in security testing. | ||
| CIS Controls v8 | CIS-18 — Penetration Testing | Testing must reflect the application’s actual runtime behaviour and exercised paths. |
| Recommendation — Use interactive testing methods where automated scanners cannot follow the full SPA flow. | ||
Practitioner Guidance
What to prioritise: Prioritise coverage of the highest-value authenticated journeys first, especially where the SPA hides transaction steps, permissions changes or API calls behind client-side transitions. If those paths are not testable, the reported result is not a reliable “pass”.
What to verify: Verify that the chosen testing method can preserve session state, wait for asynchronous rendering and confirm the backend request actually fired. If you cannot observe those states, you cannot trust the scan outcome for that workflow.
Common mistake: Treating tool output as a full security verdict when it only reflects what the crawler could see. For SPAs, incomplete coverage should trigger a change in method, not acceptance of a weaker assurance level.
Practitioner takeaway: For asynchronous SPAs, security teams should measure scanner coverage against reachable application behaviour, not against static page discovery, because blind spots are the problem to fix, not a reason to downgrade the risk.
Related resources from NHI Mgmt Group
- What should organisations do when their agent identity model cannot explain behaviour?
- What breaks when organisations cannot see behaviour changes across traders, bots, and AI agents?
- What breaks when organisations cannot see their non-human identities?
- How should organisations respond when a major IGA program cannot be completed at once?