[metafunctor]

No, I'm describing XSS. You know, where an attacker injects scripts on your pages, and the attacker's requests come from the same origin as your own requests. In CSRF, the attack is hosted outside the target site.

I don't believe a situation exists where using cookies for client-side storage is more secure than local storage. Could you please explain this in more detail?

[jakelazaroff]

Your page is mysite.com. When a user signs in, you save some sort of session token to a non-HttpOnly cookie. Your backend ignores the cookie header, and you send the session token as a different header with every request. (Basically, the same way you'd authenticate if you were to use local storage).

Now assume your page loads evilsitem.com/tracker.js. They can send requests to your backend, and the cookie will be included, but since your backend ignores the cookie header it doesn't matter. The malicious script, however, cannot access the cookie directly, since the script's origin is not the same.

That's why I say cookies used this way are strictly more secure than local storage: the fact that they're included with every request is irrelevant, and they're protected from direct access by third party scripts. Local storage is not. Even if you use JWT for auth, you should still store it in a cookie.

[metafunctor]

You are misunderstanding how the same-origin policy applies to scripts. If a page on mysite.com loads evilsite.com/tracker.js, then tracker.js runs with the same "origin" as the rest of the page that loaded it. The script has all the same access, including document.cookie, as a scripts loaded from mysite.com. Try it.

The same-origin policy only limits access between windows and frames. All scripts loaded on a page will have the same "origin".