loading...

re: Please Stop Using Local Storage VIEW POST

FULL DISCUSSION
 

I would be interested to see a followup post to give some substance to this statement (especially the scaling part):

And yes, you can most definitely scale up a large website using this pattern. Don't tell me that JWTs are “stateless” and “fast” and you have to use local storage to store them: you're wrong!

Also, if an attacker can run JS on your site, then they can also issue XHR requests which will automatically use the secure cookie for your API. It is a valid point however, that they can exfil JWT from local storage and use it from outside (by setting a fake origin header), whereas using HttpOnly cookie the attacker must call your API thru the infected browser.

P.S. Cookies are still vulnerable to CSRF unless you keep even more state on the server (anti-forgery token) and have the client send that state along with each request. Otherwise, your API can be compromised from other sites without your JS even being compromised. Maybe that will go away once SameSite cookies are widely supported.

 

I plan to do a follow-up post about this. Subscribe for updates =)

This post really blew up since I've been away @ work. There are a lot of cool writing ideas I've gotten since publishing this initial piece to dive into other related topics and help clarify a lot.;

 

Given a 2 minute expiration, and 1 request per second, Facebook for example, could nominally reduce the number of IdP requests (if they had to retrieve a session from the IdP) by almost 120 times (assuming an unsigned JWT, which isn't realistic, but is useful from a Fermi estimation).

Yes the main advantage of not using cookies is to not have to worry about CSRF, which can be quite complicated because minimally now you have to have the server also generate a non-HttpOnly cookie from the CSRF token in order for the JS to retrieve it in order to send it out-of-band as part of the subsequent XHR request.

code of conduct - report abuse