Notifications
Clear all
Topic starter
18/08/2026 2:11 pm
TL;DR: Single-page applications create security blind spots because client-side JavaScript, asynchronous requests, and complex session handling can hide XSS, token misuse, and API exposure from traditional scanning, according to Probely. The practical issue is not SPA popularity itself but whether security controls can execute the app’s stateful logic and test its API-dependent attack surface.
NHIMG editorial — based on content published by Probely: Addressing the Hidden Risks of Single-Page Applications
By the numbers:
- Single-page applications saw a 20% increase in adoption during 2023.
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 single-page applications create identity and session risk?
A: SPAs often keep authentication state in the browser and rely on tokens to carry trust across multiple API calls.
Q: What do teams get wrong about CORS in SPA security?
A: Teams often treat CORS as a browser setting instead of part of the application’s access-control model.
Practitioner guidance
- Test rendered application states Use scanning and testing tools that execute JavaScript, follow XHR traffic, and validate the post-render state of critical pages.
- Review browser token handling Check where access tokens and session identifiers are stored, how long they persist, and whether the browser can expose them through scripts or logging.
- Validate API authorisation independently of the UI Confirm that every API endpoint enforces its own authentication and authorisation rules, even when the front end appears to gate access correctly.
What's in the full article
Probely's full article covers the operational detail this post intentionally leaves for the source:
- JavaScript-aware scanning workflow for SPAs and why rendered-state inspection changes detection quality
- API and XHR traversal behaviour that shows how dynamic requests expand the test surface
- CORS validation and configuration checks that teams can use to verify browser-origin boundaries
- Practical examples of how authenticated flows and session handling are exercised during scanning
👉 Read Probely's analysis of hidden risks in single-page applications →
Single-page application security gaps: are your scanners keeping up?
Explore further
18/08/2026 3:04 pm
SPA security is now an identity-adjacent control problem, not just a web testing problem. When session state, token handling, and API authorisation live inside the browser runtime, the application inherits identity risk that traditional scanners often under-measure. That shifts the governance question from whether a page loads correctly to whether authenticated behaviour is actually constrained. Practitioners should treat SPA testing as part of identity and access assurance, not a separate UI exercise.
A question worth separating out:
Q: How do you know SPA security testing is actually working?
A: You know testing is working when it can reproduce the app’s real interactive paths, including token handling, API calls, and state changes that occur after rendering. A good program finds issues in authenticated flows, not just in public pages. If the scanner only reports surface-level findings, coverage is probably incomplete.
👉 Read our full editorial: Single-page application security gaps are hiding in client-side flows
