Local storage isn't any better in this regard
> A lot of times local storage is much less secure
Without XSS, local storage is actually more secure. You don't have worry 'did I set up this right' because there is nothing to set up and CSRF is impossible to execute.
If you're still paranoid about XSS, CSP is your friend. Also check isTrusted on events.
CSRF has incredibly simple mitigations with cookies (SameSite=strict) and can even work across different path segments (although this tends to be uncommon) and has mitigations against XSS which local storage does not. XSS is bad in either case (CSPs aren't usually an effective mitigation for a variety of reasons[1]) but being able to outright steal the session token is worse than being able to use it in a potentially more limited context
[1]: Primarily that they're generally just not implemented and that a lot of web frameworks require incredibly loose CSPs up to and including unsafe-eval since they often need to dynamically load JS. In addition, this doesn't protect from supply chain attacks (JS that is injected as the result of it being loaded from another domain, like from a CDN for example).
True. However it's not impossible to mitigate that: https://news.ycombinator.com/item?id=48563286
But arguably it's harder to do so.
> this doesn't protect from supply chain attacks
It's a separate attack vector. It's easily mitigated by having a one week back-off before upgrading. (and as I have said already, also affects binary executables)
> unsafe-eval
Technically speaking, nothing prevents you from shipping a JS-in-JS runtime that proxies objects and bypasses eval, which is just eval without eval.
It's not a perfect mitigation for session stealing, isn't available in all cases, requires custom code to implement, and also can in some cases completely break sessions (unless they have another place where it's stored)
> It's a separate attack vector. It's easily mitigated by having a one week back-off before upgrading. (and as I have said already, also affects binary executables)
A separate attack vector for the same problem. Which is also not mitigated by dependency back-off. If you load a 3rd party script into your site, you're relying on that 3rd party not getting compromised.
For example, if I have a page
<script src="https://example.com/accel.js" />
and if "accel.js" gets maliciously replaced, it can read all of the data out of local storage. No updates on your end required.
It's even conveniently grouped by domain
There's no magic hardening going on with local storage (session storage is the same here), it's still SQLite
Even if so, calling ReadProcessMemory/process_vm_readv on another process really doesn't raise alarms that significantly because there are a lot of legitimate programs that do so
