为什么在身份验证方面 Cookie 比 localStorage 更可取

介绍

我们知道 JWT（JSON Web Token），它是行业标准 RFC 7519 中用于在双方之间安全地表示声明的方法。JWT 如今非常普遍。但是我们应该将它们存储在前端的哪里呢？

在本文中，我将分解存储令牌的两个常见位置。Cookie和LocalStorage

比较

本地存储

要使用localStorage，只需简单地调用使用localStorage对象

localStorage.setItem("yourTokenName", yourToken)
localStorage.getItem("yourTokenName", yourToken)

优点：

• 非常方便，不需要任何后端，只需要纯 JavaScript。
• 数据量大，约5mb。

缺点：

• 易受 XSS 攻击。当攻击者能够获取您存储在 localStorage 中的访问令牌，从而能够在您的网站上运行 JavaScript 时，就会发生 XSS 攻击。

曲奇饼

要设置cookie，我们可以这样做：

document.cookie = "cookieName=value"

或者使用 http 请求执行此操作：

Set-Cookie: <cookie-name>=<cookie-value>

优点：

• 如果您使用 httpOnly 和安全 cookie，这意味着无法使用 JavaScript 访问您的 cookie，因此即使攻击者可以在您的网站上运行 JS，他们也无法从 cookie 中读取您的访问令牌。
• 可以设置到期日期

缺点：

• 仅 4kb 存储空间

安全问题

XSS攻击

正如我上面所说，本地存储很容易受到攻击，因为它很容易通过 JavaScript 访问，攻击者可以获取你的访问令牌。然而，虽然httpOnly无法通过 JavaScript 访问 Cookie，但这并不意味着使用 Cookie 就能免受涉及访问令牌的 XSS 攻击。

如果攻击者可以在您的应用程序中运行 JavaScript，他们只需向您的服务器发送 HTTP 请求，其中就会自动包含您的 cookie；这对攻击者来说不太方便，因为他们无法读取令牌的内容，尽管他们可能不需要这样做。

CSRF攻击

跨站请求伪造（也称为 CSRF）是一种网络安全漏洞，它允许攻击者诱使用户执行他们不想执行的操作。

sameSite但是，通过在 cookie 中包含反 CSRF 令牌，可以使用标志轻松缓解此问题。

结论

Cookie 仍然存在一些漏洞，但只要条件允许，它总是比 localStorage 更可取。原因如下：

和 都localStorage容易cookies受到 XSS 攻击，但使用 httpOnly Cookie 时，攻击者更难发动攻击。Cookie
容易受到 CSRF 攻击，但可以使用 sameSite 标志和反 CSRF 令牌来缓解。
即使您需要使用 Authorization: Bearer 标头或您的 JWT 大于 4KB，您仍然可以使其正常工作。