3 ms·

I am one of the guilty parties here. I love local/session storage and I have used it frequently in web app development, and while I came to the same conclusions

I am one of the guilty parties here. I love local/session storage and I have used it frequently in web app development, and while I came to the same conclusions expressed in the article, I have come up with quite a few ways to mitigate these. First, I’ve written several private utilities that handle session/local storage in much more graceful and intelligent ways than you would by using it “raw”. Perhaps I should publish one of these one day, but they basically do the following: 1) Store everything in base-64 encoded JSON so you can interact with the storage API using regular JavaScript objects. 2) Use ambiguous keys, and 3) implement async support. I have used this with great success to do things like caching large API responses as well as store non-sensitive user data. On the other hand, even though the information is encoded, it could easily be decoded, so I would not ever store PII data this way. But even if you wanted to store sensitive data, it wouldn’t be a far stretch to implement some kind of encryption. Sorry for the awful formatting, I am writing this in mobile.

SahAssar 6y ago
> implement async support How can that be possible? The underlying API is blocking and the localStorage interface is not available in web-workers. > But even if you wanted to store sensitive data, it wouldn’t be a far stretch to implement some kind of encryption. Since any other JS runs in the same environment and thread with access to the same resources how would encryption help with the issues in the article?
- Anunayj 6y ago
  Encrypting all sensitive information that gets stored with a public key received from server. That saves bandwidth compared to cookies, any rouge plugins/javascript won't be able to decrypt the data. (and the client too won't be able to, kinda a bummer). The server will be able to decrypt it obviously since it should have the corresponding private key.
  - SahAssar 6y ago
    Any other JS could still read the encrypted data and exfiltrate it, and use it in the same way as the "real" client since they can both see and use the same data. What you are describing is very similar to how JWT already works (at least in the JWE variant which is encrypted, not only signed). If you want to save bandwidth the easiest way is to have a separate subdomain for API requests or asset requests so you don't send the cookie with asset requests. I don't think that is worth it for 99% of sites though.

SahAssar 6y ago

> implement async support How can that be possible? The underlying API is blocking and the localStorage interface is not available in web-workers. > But even if you wanted to store sensitive data, it wouldn’t be a far stretch to implement some kind of encryption. Since any other JS runs in the same environment and thread with access to the same resources how would encryption help with the issues in the article?

Anunayj 6y ago
Encrypting all sensitive information that gets stored with a public key received from server. That saves bandwidth compared to cookies, any rouge plugins/javascript won't be able to decrypt the data. (and the client too won't be able to, kinda a bummer). The server will be able to decrypt it obviously since it should have the corresponding private key.
- SahAssar 6y ago
  Any other JS could still read the encrypted data and exfiltrate it, and use it in the same way as the "real" client since they can both see and use the same data. What you are describing is very similar to how JWT already works (at least in the JWE variant which is encrypted, not only signed). If you want to save bandwidth the easiest way is to have a separate subdomain for API requests or asset requests so you don't send the cookie with asset requests. I don't think that is worth it for 99% of sites though.