The "where to store JWTs" debate is complicated and not without nuance. It's important to realize that there is no 100% secure answer.
That is to say, whatever answer you give, there are associated weaknesses that you must be aware of.
A lot of people will argue that if your app is vulnerable to XSS, cookies with HttpOnly are at least protected from JavaScript, while Session/Local Storage are designed to be accessed by JavaScript.
This might seem like cookies have a big advantage, but what this really means is that cookies cannot be stolen. However, since the browser automatically adds cookies to requests, any XSS attack could send valid requests and steal the data from them. So yes, while you don't get the actual session token, you can still use it, which is ultimately what an attacker wants to do anyway.
Moreover, if you rely on cookies, your app needs to protect itself against CSRF. This has become easier with SameSite cookie attributes, but they are not without their limitations ().
If you use Session/Local Storage and set session tokens via a non-Cookie header (e.g. Authorization), CSRF is impossible. It's important to note that if your app is vulnerable to XSS, all your CSRF protections will fail regardless of how you store session tokens.
Finally, people suggesting Session Storage over Local Storage face the issue that Session Storage is per-tab not per-site. If you store a session token in Session Storage, then right-click a link in your app and "Open in new tab", you will be logged out in that new tab.
This is not me arguing for / against a particular method. As I said at the start, there is no 100% secure solution. This is a brain dump of some of the weaknesses each has so people can make more educated decisions. 🤷portswigger.net/web-security/c…
That is to say, whatever answer you give, there are associated weaknesses that you must be aware of.
A lot of people will argue that if your app is vulnerable to XSS, cookies with HttpOnly are at least protected from JavaScript, while Session/Local Storage are designed to be accessed by JavaScript.
This might seem like cookies have a big advantage, but what this really means is that cookies cannot be stolen. However, since the browser automatically adds cookies to requests, any XSS attack could send valid requests and steal the data from them. So yes, while you don't get the actual session token, you can still use it, which is ultimately what an attacker wants to do anyway.
Moreover, if you rely on cookies, your app needs to protect itself against CSRF. This has become easier with SameSite cookie attributes, but they are not without their limitations ().
If you use Session/Local Storage and set session tokens via a non-Cookie header (e.g. Authorization), CSRF is impossible. It's important to note that if your app is vulnerable to XSS, all your CSRF protections will fail regardless of how you store session tokens.
Finally, people suggesting Session Storage over Local Storage face the issue that Session Storage is per-tab not per-site. If you store a session token in Session Storage, then right-click a link in your app and "Open in new tab", you will be logged out in that new tab.
This is not me arguing for / against a particular method. As I said at the start, there is no 100% secure solution. This is a brain dump of some of the weaknesses each has so people can make more educated decisions. 🤷portswigger.net/web-security/c…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
