> The CSRF attacks you're describing have been solved by browsers with the SameSite attribute on cookies. This is only partially true; It requires the users to

> The CSRF attacks you're describing have been solved by browsers with the SameSite attribute on cookies. This is only partially true; It requires the users to have browsers which respect this. Which is probably true for 99% of users now, but not 100% (pasting a comment from a project I worked on recently): /* 'lax' means cookies will not be sent for cross-domain requests on modern browsers, except from top-level navigations with a GET or HEAD request (which are safe). This mitigates CSRF without any additional token handling in browsers Edge (since 2017), Firefox (since 2018), Chrome (since 2016), and Safari (since 2018) */ > In choosing localstorage over HttpOnly cookies, you've put yourself at greater risk in the event of an XSS attack (meaning, an attacker running their javascript code on your own domain). XSS an issue regardless of whether SameSite is set, they just can't access the session cookies via Javascript (assuming HTTPOnly is also set). An attacker that was able to inject a script into a user's browser on your own domain can get around CSRF protection, and session cookies will be sent. The only disadvantage localstorage has over this is that it can be sent to the attacker's server as well. I agree cookies are much better for auth* information; if we're using JWT, those can fortunately be put in localstorage also right?