Questions on rigidity of token-based session storage, "sessionStorage for token-based sessions" guidance in 8.2.2 #1141
Description
Hi all, I read through #843 and #1091 to see that the bleeding edge has some exceptions for token-based session storage.
From the change to 8.2.2 it appears (from my understanding) that two types of sessions are mentioned:
- cookie-based sessions: Sessions where an application server sets the cookie with a Set-Cookie header (HTTP-Only), and the domain of the cookie is the recipient of authorized API requests. There is no reason why client JS would need to access the session, which is the basis for the clarification in 8.2.2.
- token-based sessions: Tokens used by browser clients (delegated access token, for example) that are attached as Authorization headers to outbound CORS requests. Token storage for these sessions in the browser seems to be a necessary evil, and the guidance is to use sessionStorage.
My question is, the session distinction makes sense, but should sessionStorage be mentioned here at all?
Storage for token-based sessions comes up in the first place because of two persistence needs:
- Session retention across page refreshes
- Session retention across browser tabs of the same application
The sessionStorage exception only solves persistence need 1, but not persistence need 2. The only path forward for these types of applications is to initiate new token-based sessions per tab, which requires a new login/authorization per tab. This doesn't really make the client more secure from a storage perspective, since XSS can still steal tokens from sessionStorage, and also adds a lot of complexity to the app for session management. It, in my opinion, opens up even more questions (and potentially insecure solutions) about how to securely manage token-based sessions across tabs, which doesn't seem to be covered.
Should there be specific guidance about which browser storage to use for token-based sessions? All browser storage is inherently insecure because of XSS, so what benefit does sessionStorage provide that it is worth being called out?
| Storage | Susceptible to XSS | Susceptible to Token Exfiltration | Meets Persistence Need 1 | Meets Persistence Need 2 | Notes |
|---|---|---|---|---|---|
| Web Workers | Yes | No | ✅ | ✅ | Accessible across tabs if SharedWorker is used. Potentially complex to set up. |
| In-memory Closures | Yes | No (?) | - | - | Only available within current tab. |
| Session Storage | Yes | Yes | ✅ | - | Only available within current tab. |
| Cookie - Samesite=Strict, Secure, not HTTP-Only (essentially "stricter" local storage) | Yes | Yes | ✅ | ✅ | Expires when token expires if expiration is set (or additionally when browser is closed if set as a session cookie). If used purely for storage, does not open itself up for CSRF, because outbound requests require attached Auth Headers. |
| Local Storage | Yes | Yes | ✅ | ✅ | Accessible within domain. No expiration, needs to be manually cleared by the client, but 8.2.3 covers this. |
Should the distinction instead be something along the lines of:
Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of cookie-based session tokens and token-based session tokens, with the former stored only in cookies, following V3.4.
Very curious on thoughts here. Also, let me know if there is another discussion somewhere discussing this.