Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I've read that it's a bad idea to save Single Page App's encrypted authentication token in browser's localStorage because this makes your app vulnerable to XSS attack, and when the token is stolen, the hacker can disguise as the user and do whatever evil.
But as far as I know cookies are also vulnerable to XSS hijacking.
So I'm wondering what's the difference if any? And how the risks of the two methods are compared
A cookie marked httpOnly, as the name implies, cannot be accessed from javascript. So a 'conventional' web application using cookies is not vulnerable to naive XSS attacks if that flag is set (assuming no browser bugs expose it of course.) Notably such a solution is vulnerable to CSRF, so more work is required to mitigate that.
In SPA frameworks you generally need access to the cookie in javascript anyway because they want to put it in an authorization header, not simply rely on "old school" cookie based security. This has the advantage of now being CSRF resistant.
The basic rationale for an SPA is if someone manages to inject javascript they have won. You must not have XSS vulnerabilities because the attacker can alter anything about your entire application and simply do inside the victim's own browser whatever malicious thing they would have done with the stolen token. (or simply alter your app to steal the user's plaintext password...)
Therefore people choose to tolerate the potential exposure of the session token, because the assumed consequence of a successful XSS on an SPA is 100% compromise anyway.
(In my opinion this is by no means a settled topic, people are still having nasty arguments about it. There's endless blog posts and forum flame wars advocating on both sides.)
