I just want to jump in real quick as one of those people who like to use articles like this to make blanket decisions. A few points as why security people say not to store session data in JWT and LocalStorage. Out of the box yes LocalStorage is more secure than a cookie for session data, however with the optional flag SameSite cookies are now equal to LocalStorage with built-in anti CSRF protections from the browser. Adding the HTTPOnly flag bring cookies to a higher level than LocalStorage. This is because now client-side JavaScript cannot access the cookies. The last part is where the recommendation to use cookies over LocalStorage is made in relation to potential exposure from XSS. Outside of XSS or vulnerabilities in the browser itself both are limited to exposure from physical access on the client-side in a general risk perspective.
The biggest risk for both options from a security perspective is XSS and while some may be confident in their ability to not introduce XSS, I can say that even the most experienced developers can have a hard time preventing XSS. I won't dive into too specific details but a shockingly common bypass to a lot of anti-XSS solutions is to switch the method from GET to POST or POST to GET in a request. Some popular frameworks even allow submitting GET parameters in the body which is completely wrong from the RFC point of view. The pervasiveness of XSS is why security people make the recommendation, we like to think in layers so if XSS is somehow introduced into the application you still have the layer from HTTPOnly on the cookie verse no additional layer on the LocalStorage side.
TLDR: LocalStorage out of the box is less insecure, but cookies offer more security than LocalStorage when done right. Security people aren't blindly making the recommendation there is a reason.
I would argue that using an httpOnly cookie doesn't add any security. At best you could say that it might make it slightly less convenient for an attacker to carry out the XSS attack.
Concur. There's no threat modeling that I could think of that would hold up httpOnly as being a significant factor if the threat vector up to that point has already leveraged XSS - so your local JS context is already 0wned - at this point, the exploit code just needs to directly execute from the compromised browser instead of sending the auth token to a remote server to be exploited from there. Considering the local context is already compromised, that hardly seems more than an inconvenience to the attacker, as jondubois indicated.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I just want to jump in real quick as one of those people who like to use articles like this to make blanket decisions. A few points as why security people say not to store session data in JWT and LocalStorage. Out of the box yes LocalStorage is more secure than a cookie for session data, however with the optional flag SameSite cookies are now equal to LocalStorage with built-in anti CSRF protections from the browser. Adding the HTTPOnly flag bring cookies to a higher level than LocalStorage. This is because now client-side JavaScript cannot access the cookies. The last part is where the recommendation to use cookies over LocalStorage is made in relation to potential exposure from XSS. Outside of XSS or vulnerabilities in the browser itself both are limited to exposure from physical access on the client-side in a general risk perspective.
The biggest risk for both options from a security perspective is XSS and while some may be confident in their ability to not introduce XSS, I can say that even the most experienced developers can have a hard time preventing XSS. I won't dive into too specific details but a shockingly common bypass to a lot of anti-XSS solutions is to switch the method from GET to POST or POST to GET in a request. Some popular frameworks even allow submitting GET parameters in the body which is completely wrong from the RFC point of view. The pervasiveness of XSS is why security people make the recommendation, we like to think in layers so if XSS is somehow introduced into the application you still have the layer from HTTPOnly on the cookie verse no additional layer on the LocalStorage side.
TLDR: LocalStorage out of the box is less insecure, but cookies offer more security than LocalStorage when done right. Security people aren't blindly making the recommendation there is a reason.
I would argue that using an httpOnly cookie doesn't add any security. At best you could say that it might make it slightly less convenient for an attacker to carry out the XSS attack.
I wrote a more detailed technical explanation here: dev.to/jondubois/comment/373l
Concur. There's no threat modeling that I could think of that would hold up httpOnly as being a significant factor if the threat vector up to that point has already leveraged XSS - so your local JS context is already 0wned - at this point, the exploit code just needs to directly execute from the compromised browser instead of sending the auth token to a remote server to be exploited from there. Considering the local context is already compromised, that hardly seems more than an inconvenience to the attacker, as jondubois indicated.