[szmarczak]

> A lot of times local storage is much less secure than using cookies.

Is it? If an attacker can't do XSS then it's as strong as cookies.

Supply chain attacks aren't an argument here because they can also happen with cookies. CSRF as well. The same can happen in actual executable binaries.

I don't get the 20 yr age argument:

- HttpOnly fights XSS which is impossible to execute with modern frontend frameworks.

- SameSite fights CSRF but the real solution is to disable loading the website in iframes (remember clickjacking?).

- Secure fights MITM which is already fixed by default when using local storage and HSTS is the real deal.

Having said that, I'd say that local storage is more secure than cookies (no need to remember whether you put Secure on or not). Unless you're still using PHP, which means touch grass.

[jkrejcha]

> - HttpOnly fights XSS which is impossible to execute with modern frontend frameworks.

Eh. Frontend frameworks tend to make successful XSS much worse because they tend to require disabling HttpOnly for not very good reasons. HttpOnly is a nice defense in depth measure against the consequences of XSS.

> - SameSite fights CSRF but the real solution is to disable loading the website in iframes (remember clickjacking?).

Disabling iframes doesn't fix CSRF. You can still <form method="..." /> or <img /> tags or whatever. For an example, see these universal logout pages. SameSite helps with CSRF (you really should also using CSRF tokens as the primary control and maybe using the Sec-Fetch-X headers as well).

[szmarczak]

> they tend to require disabling HttpOnly for not very good reasons

First time I'm hearing that frameworks require disabling HttpOnly.

> Disabling iframes doesn't fix CSRF. You can still <form method="..." /> or <img /> tags or whatever.

Obviously. IMG tags don't work because of CORS (unless you explicitly allow this) nor script tags etc. Browsers send Origin and Sec-Fetch- headers which you can use to block POST navigation requests from other origins, like you mentioned.

But when you're using tokens in JavaScript then you don't have to worry because you already have your CSRF token, which is inaccessible to third parties and no form submit will include it. That's why local storage is more secure.

[jkrejcha]

> First time I'm hearing that frameworks require disabling HttpOnly.

They effectively do in the case where you're using local storage because they need to grab the session token from somewhere. The thing about HttpOnly is that JS code never even gets to see the session token. Which is a mitigation for a whole class of vulnerabilities.

> ...CSRF

You have to mitigate CSRF server-side (with a CSRF token, checking the Sec-Fetch-* headers) or by using SameSite on the client side (ideally both)

There's a reason "don't use local storage for security sensitive stuff" is part of the OWASP cheatsheet[1]

[1]: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Securit...

[szmarczak]

> There's a reason "don't use local storage for security sensitive stuff" is part of the OWASP cheatsheet

Local storage was released more than 16 years ago, and back then PHP was wayy too popular. XSS is almost impossible to execute these days (unless you do selfxss).

Discord has mitigations for grabbing the token from local storage: https://news.ycombinator.com/item?id=48563286

[szmarczak]

> You have to mitigate CSRF server-side (with a CSRF token

> when you're using tokens in JavaScript then you don't have to worry because you already have your CSRF token

No reason to have a dedicated CSRF token because your local storage token already works as a CSRF token.