[szmarczak]

> XSS which local storage does not [mitigate]

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.

[jkrejcha]

> True. However it's not impossible to mitigate that: https://news.ycombinator.com/item?id=48563286

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.

[szmarczak]

> isn't available in all cases

Which ones? Websites that ship no JavaScript? All browsers support this.

> can in some cases completely break sessions

Or you can just remove local storage from window and have it just for yourself, which seems what Discord is doing as well.

Attackers cannot use local storage because there is no local storage on the window object.

> A separate attack vector for the same problem

It's not exactly the same problem. The example you mentioned is a footgun because you don't vendor your dependencies. Deliberately giving someone else access to your website is an issue in itself.

[jkrejcha]

In the Discord case they can just call the `getToken()` function. It's not on `window`, but it's trivial to find.

The mitigation is rough on systems where SIGKILL happens early and often. Presumably this is why Discord doesn't do this on mobile. You switching out of the app has a much higher likelihood of that happening than on other platforms. You can't rely on onunload ever getting a chance to run

This also has barely anything to do with local storage, you could do the same for cookies. But with cookies, the browser blocks JS from getting your tokens at all if you use HttpOnly and don't leak it in responses or whatnot, so you don't need to (though you certainly can delete window.cookies if you want as well)