Single page applications (SPAs) shift work from the server to the browser, and the risks shift with it. The common ones are DOM based cross site scripting, tokens stored where scripts can read them, API endpoints exposed in shipped JavaScript, and access checks that exist only in client code.
Why does moving to the browser change the risk?
A traditional server rendered page builds HTML on the server, where templates can escape output in one place. An SPA ships a JavaScript bundle that builds the page in the user's browser and talks to APIs for data. Three things follow. The code is public, because anyone can read it. The state lives in the client. And untrusted data is written into the page by your own scripts, often in many places.
Is DOM based XSS the main worry?
It is the classic one. In DOM based XSS the dangerous write happens in client side code, for example assigning untrusted data to a property that parses HTML. The OWASP DOM based XSS Prevention Cheat Sheet explains that the safe pattern depends on the context where data lands, whether HTML, an attribute, a script, a style or a URL, and it recommends using safe sinks that treat data as text rather than markup.
Frameworks escape output by default, which removes most accidents. The risk returns when someone uses an escape hatch that inserts raw HTML, or builds a URL from user input and assigns it to a link or redirect. Review every use of those escape hatches.
Where should tokens live?
Authentication tokens are a frequent design question. The OWASP HTML5 Security Cheat Sheet warns about storing sensitive data in browser storage that any script on the page can read, since a single XSS flaw then exposes it. Cookies marked HttpOnly cannot be read by scripts, but cookies sent automatically raise cross site request forgery questions, which the OWASP CSRF Prevention Cheat Sheet covers with token and SameSite based defenses.
Neither choice is free. The point is to choose on purpose and pair it with strong XSS defenses and a content security policy.
What do bundles reveal?
Everything the browser can call is findable. API paths, feature flags, internal hostnames and sometimes keys end up in the bundle or in its source maps. This is not a flaw by itself, since the browser needs the routes. It becomes one when the server trusts that nobody will call an endpoint the interface does not show. Hidden admin routes and debug endpoints are easy to find in a minified file.
Are client side checks enough?
Never. A check in JavaScript that hides an admin button is a usability feature. Authorization has to be enforced on the server for every request, because an attacker can call the API directly without your interface at all.
Constructed example: the hidden export
An SPA has an Export all users button, shown only when the user's role is admin. The bundle contains the route for it. The server checks that the caller is logged in but not that they are an admin. Any user who reads the bundle and sends the request gets the export. The fix is a server side role check on that route, plus a test that calls it as a normal user.
How to check or apply this
- Search the codebase for raw HTML insertion and dynamic URL assignment, and justify or remove each one.
- Decide where session tokens live, document why, and set cookie flags accordingly.
- Deploy a content security policy and test that it blocks inline script.
- List every API route in the bundle and confirm each enforces authorization on the server.
- Disable public source maps in production unless you have a reason, and scan dependencies, since SPAs often pull in hundreds of packages.
On the dependency point, reachability analysis helps separate libraries that your bundle actually calls from ones that only sit in the lockfile.
Quick check
Do modern frameworks make XSS impossible?
No. They escape output by default, but raw HTML escape hatches, unsafe URLs and third party scripts can still introduce it.
Is hiding a route in the interface a security control?
No. Routes in the bundle can be called directly, so the server must enforce authorization on each one.
Sources
- OWASP DOM based XSS Prevention Cheat Sheet
- OWASP HTML5 Security Cheat Sheet
- OWASP CSRF Prevention Cheat Sheet
Last reviewed: 18 October 2026.
