将token存储在浏览器sessionStorage是否为良好实践？客户端存储方案如何选？

把Token存储在sessionStorage是否属于良好实践？ #

先说结论：这只能算有特定适用场景的折中方案，算不上通用的良好实践。
它的优势很明确：

• 生命周期和当前标签页绑定，关闭标签页就自动清空，不会在多标签页之间共享，一定程度降低了登录态跨页面泄露的风险
• 不会被浏览器自动附加到HTTP请求中，天然免疫CSRF攻击

但缺陷也非常突出：

• 完全没有XSS防护能力，只要页面被注入恶意脚本，攻击者可以直接通过sessionStorage.getItem()读走所有存储内容，Token会直接泄露
• 标签页关闭即失效，用户新开标签页访问同站点需要重新登录，使用体验很差
• 无法实现同站点多标签页登录态共享，多开场景下用户需要重复登录多次，适用性很窄

浏览器各类客户端存储方案哪一种更优？ #

不存在绝对的最优方案，要结合存储内容的性质、生命周期要求、安全等级来选，主流方案的适用场景如下：

• 存鉴权Token这类高敏感信息：优先选带HttpOnly、Secure、SameSite属性的Cookie。这是目前安全等级最高的客户端存储方案，XSS脚本无法直接读取存储内容，只要配合做好CSRF防护（比如请求加CSRF Token校验、校验Referer/Origin），就能覆盖绝大多数业务的安全需求。
• 存单标签页生命周期内的非敏感临时数据：选sessionStorage。比如单页应用的页面临时状态、未提交的表单草稿等场景都很合适，用完自动清不会占存储空间。
• 存长期有效的非敏感公共配置：选localStorage。比如用户的UI主题偏好、站点全局配置这类不需要服务端参与的内容，它的存储空间有5MB左右，比Cookie大很多，用起来也方便，但绝对不能存任何敏感信息。
• 存大容量结构化离线数据：选IndexedDB。比如离线应用的缓存数据、大量本地业务数据的存储，性能比localStorage好很多，支持事务、查询等数据库能力，同样不适合存敏感内容。

内容的提问来源于stack exchange，提问作者ng_dev