对于Session来说，Cookie可以比LocalStorage更安全的保存Session Token。

具体可以查看这篇文章：Cookies vs Localstorage for sessions – everything you need to know

下面通过几个属性比较不同浏览器存储机制。

Session Storage：大多数应用程序即使打开多个浏览器选项卡或重新启动浏览器也要求用户登录，因此这种方法不能用于保存用户登录状态（不要被其名称所欺骗）。

IndexedDB：Session Token 是键值对。因此，它们不需要复杂的查询功能。从技术上讲，可以使用IndexedDB作为一种选择，但是，与出于存储和检索会话令牌的目的而使用localstorage相比，它将更加复杂。

我们可以选择在Local Storage和Cookie存储之间进行选择。

我们将从可用性和安全性的角度比较这些存储类型。为了提高可用性，我们将考虑编写，读取和删除会话令牌的简便性，以及每种存储类型对特定用例所施加的任何限制。

从安全角度来看，我们将考虑可用于每种存储类型的令牌滥用或盗窃的不同方法。

1.大小限制：Cookie的大小限制为每个域4kb，而本地存储大小则大一个数量级。在大多数情况下，即使使用JWT，4kb足以存储Session Token。

Cookie：1；本地存储：1

2.自动管理：Cookies由浏览器自动保存，发送和删除。前端开发人员不必担心实现此部分，也不必担心前端存在任何错误。对于本地存储，情况并非如此。

Cookie：2；本地存储：1

3.服务端渲染的应用程序：在进行浏览器级别的导航（用户在其浏览器中键入URL /在新选项卡上打开链接）时，仅发送Cookie。这意味着，对于那些对服务器的API调用，只有在使用Cookie的情况下，它们才会获得Session Token-本地存储将不起作用。

Cookie 3；本地存储1

4.在子域名之间共享相同的会话：此处的目的是，用户导航到站点的不同子域时应使用相同的会话。通过将Cookie域设置为“ .yoursite.com”，可以通过Cookie轻松完成此操作。

由于存储不是跨域/子域共享的，因此通过LocalStorage很难做到这一点。可以使用iframe来解决这个问题，但这并不容易。

Cookie：4；本地存储：1

1.通过XSS攻击对令牌的滥用：当将“恶意” JavaScript注入网站时，就会发生XSS攻击。可能发生这种代码注入的方式包括不正确的输入/输出验证，将恶意的第三方脚本加载到站点的前端代码或社会工程中。

如果使用本地存储，则恶意JS代码可以轻松读取会话令牌并将其传输给攻击者。然后，攻击者会将这些令牌放到他们的浏览器中，并且即使没有完全访问该用户帐户，也具有重要的访问权限。

Cookies具有称为httpOnly的特殊标志。如果设置，它将阻止前端的任何JS读取该cookie的值。这意味着恶意JS代码无法将访问令牌发送给攻击者。但是，当用户使用该网站时，该代码仍然可以进行恶意API调用。根据产品和攻击原因，这可能不足以满足攻击者的意图。

Cookie：5；本地存储：1

2.通过CSRF攻击对令牌的滥用：这是一种攻击，它迫使最终用户在当前已通过身份验证的Web应用程序上执行不需要的操作。当用户访问第三方恶意站点时，将执行此有害操作。仅当使用cookie来存储访问令牌时，这种攻击才可能发生。但是，也可以使用Cookie中的anti-csrf令牌或sameSite标志轻松缓解这种情况。无论如何，在使用本地存储时，无需考虑这种攻击媒介。

Cookie：5；本地存储：2

3.通过恶意软件盗取代币：这是一个日益受到关注的问题。实际上，由于他们的会话令牌是通过计算机上的恶意软件窃取的，许多大型的Youtube订户帐户遭到了劫持。由于社交工程攻击，他们感染了此恶意软件。本地存储和cookie存储都不会有所作为，以缓解这种攻击（因此，两者均不会获得任何积分）。这里唯一可以采取的措施是进行令牌盗窃检测[1]。

Cookie：5；本地存储：2

根据最终得分（Cookie：5； LocalStorage：2），很明显，安全的httpOnly cookie是存储Session Token的正确方法。这也是OWASP社区的建议[3]。