[FiddlyPack]

Highlights, to me:

- do not trust localStorage

- quote: The most challenging pattern in our dataset consists of scenarios in which applications use the persistence mechanisms to deliberately store HTML or JavaScript code, e.g., for client-side caching purposes. In this setting, the attacker is able to completely overwrite the contents of the corresponding storage entry with their own code. We could identify in several cases these flaws are actually introduced by third-party libraries, among them CloudFlare and Criteo.

[joeyrideout]

Isn't "do not trust localStorage" another variant of "do not trust the client"?

Taking client-controlled storage and inserting it unsafely into the DOM sounds like a bad idea, although it's not something that is popularly discussed as a trust boundary so awareness is key (this article is a great example).

[FiddlyPack]

Exactly so. The use case of Local Storage is usually “application cache.” When you’re building out features, it may not even be obvious that you’re injecting application state _that originated in localStorage_ into the DOM. That’s why this is such an easy problem to fall into.