It depends what you mean by the term "associated browser security." The method they are describing stops CSRF attacks dead in their tracks (e.g. if dev set up a GET endpoint that should have been POST/PUT), prevents plaintext cookies from being stored in a nicely organized sqlite db on disk, and limits the scope of xss (xss on a 404 page would get you nothing).
> Aren't cookies restricted for a reason? Can't anyone who can execute JS on that domain can swipe the JWT token out of storage and then impersonate the user?
HTTP-only cookies prevent attacker from swiping yes, but if you have the ability to execute JS on an arbitrary domain, you can just do your XSS attacks there, the browser will attach the cookie, and attacker has already won.
Of course it is not a perfect solution. Just more depth. XSS into a page that inlines auth details = instant pwn, but that was already true anyways. Inlining cred info into my javascript gives be a bad feeling too.
> Aren't cookies restricted for a reason? Can't anyone who can execute JS on that domain can swipe the JWT token out of storage and then impersonate the user?
HTTP-only cookies prevent attacker from swiping yes, but if you have the ability to execute JS on an arbitrary domain, you can just do your XSS attacks there, the browser will attach the cookie, and attacker has already won.
Of course it is not a perfect solution. Just more depth. XSS into a page that inlines auth details = instant pwn, but that was already true anyways. Inlining cred info into my javascript gives be a bad feeling too.