LocalStorage vs Cookie for JWT Access Token war in short
There is a war between LocalStorage/SessionStorage and Cookie for storing access tokens. Which one is more secure?
Let’s tackle some simple arguments first.
Cookies are vulnerable to CSRF attacks. This is preventable, most modern frameworks can generate/handle CSRF/XSRF tokens automatically. This is something you need to be aware of when using cookies, but this shouldn’t be the reason for not using cookies as storage for access tokens.
Stateful vs Stateless. Some people claim they have a stateless API and cookies are not stateless. Along a similar line, cookies are not as scalable because you have to have centralised session storage in the backend. This is simply wrong. Cookies are just HTTP headers
Cookie: accessToken=value;Similar to the Authorization header if you use localStorage
Authorization: Bear <access-token>Using cookies doesn’t mean you have to implement a traditional session in your API. You can handle cookies the same way you handle the authorization headers e.g. read the JWT access token from cookies, verify and find the user id from the payload.
Consistent Authentification Method Across Platforms. Some people say you should use local storage because it allows you to use the “Authorization: Bearer <token>” to authenticate your web app so it is consistent with the way your mobile app authenticates users. This is a very weak argument. Why sacrificing your web app’s security for your mobile app. They are completely different platforms with different security measures. Do you wear a helmet on a plane?
The Final War: XSS
LocalStorage/SessionStorage is vulnerable to XXS attacks. Access Token can be read by JavaScript.
Cookies, with httpOnly, secure and SameSite=strict flags, are more secure. Access Token and its payload can not be accessed by JavaScript.
BUT, if there is an XSS vulnerability, the attacker would be able to send requests as the authenticated user anyway because the malicious script does not need to read the cookie value, cookies could be sent by the browser automatically.
This statement is true but the risks are different.
With cookies, the access token is still hidden, attackers could only carry out “onsite” attacks. The malicious scripts injected into the web app could be limited, or it might not be very easy to change/inject more scripts. Users or web apps might need to be targeted first by attackers. These conditions limit the scale of the attack.
With localStorage, attackers can read the access token and carry out attacks remotely. They can even share the token with other attackers and cause more serious damage. If attackers manage to inject malicious scripts in CDNs, let’s say google fonts API, attackers would be able to siphon access token and URLs from all websites that use the comprised CDN, and easily find new targets. Websites that use localStorage are more easily to become targets.
For the sake of arguments
A pen-testing might flag your use of localStorage for sensitive data as a risk.
If it was ok for JavaScript to read access token from localStorage from an XSS attack, why do you think the httpOnly flag is still recommended by everyone.
Recommendation from OWASP
Do not store session identifiers in local storage as the data is always accessible by JavaScript. Cookies can mitigate this risk using the httpOnly flag.
OWASP or a random green tick on StackOverflow telling you localStorage is fine. The choice is yours.
