6 ms·
> 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
by jkrejcha 3mo ago
> 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_Security_Cheat_Sheet.html#local-storage https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Securit...
- szmarczak 3mo ago> 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.
- jkrejcha 3mo agoIt simply doesn't mitigate CSRF by itself
- szmarczak 3mo ago> 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 https://news.ycombinator.com/item?id=48563286