token 应该存在 Cookie、SessionStorage 还是 LocalStorage 中？

在Web开发中，token（令牌）可以存储在多个地方，包括cookie、sessionStorage和localStorage。每种存储方式都有其优点和缺点，选择哪种方式取决于你的应用需求。 1. Cookie：将token存储在cookie中是一种常见的做法。这种方式的优点是，即使在浏览器关闭后，cookie仍然存在，因此用户可以保持登录状态。然而，cookie的缺点是容易受到CSRF（跨站请求伪造）攻击。 2. SessionStorage：将token存储在sessionStorage中的优点是，它只在当前会话中存在，当用户关闭浏览器后，sessionStorage中的数据将被清除。这种方式的缺点是，如果用户在浏览器中打开新的标签页或窗口，那么新的页面将无法访问sessionStorage中的数据。 3. LocalStorage：将token存储在localStorage中的优点是，即使在浏览器关闭后，localStorage中的数据仍然存在，因此用户可以保持登录状态。此外，localStorage中的数据可以在同一浏览器的所有标签页和窗口中共享。然而，localStorage的缺点是容易受到XSS（跨站脚本）攻击。 总的来说，将token存储在哪里取决于你的应用需求。如果你的应用需要在用户关闭浏览器后保持登录状态，那么你可以选择将token存储在cookie或localStorage中。如果你的应用需要在用户关闭浏览器后清除token，那么你可以选择将token存储在sessionStorage中。 在Web开发中，安全性是非常重要的。无论你选择哪种存储方式，都需要采取适当的安全措施，以防止CSRF和XSS攻击。

针对存在 cookie 中的 token 如何避免 CSRF 攻击？

1. 使用SameSite属性：在设置cookie时，可以使用SameSite属性来防止CSRF攻击。SameSite属性可以设置为Strict、Lax或None。当设置为Strict时，cookie只会在同源请求中发送。当设置为Lax时，cookie会在同源请求和顶级导航（例如链接点击）中发送。当设置为None时，cookie会在所有请求中发送，但这需要Secure属性同时设置为true。 2. 使用CSRF Token：在每个请求中添加一个随机生成的CSRF Token，然后在服务器端验证这个Token。如果Token不匹配，那么请求将被拒绝。 3. 使用Referer Header：在服务器端检查Referer Header，如果请求不是来自同一源，那么请求将被拒绝。

针对存在 localStorage 中的 token ，如何避免 XSS 攻击？

1. 使用Content Security Policy（CSP）：CSP可以限制浏览器只加载和执行来自特定源的脚本，从而防止XSS攻击。 2. 对用户输入进行验证和转义：对所有用户输入进行验证，并对特殊字符进行转义，以防止恶意脚本被执行。 3. 使用HttpOnly属性：虽然HttpOnly属性不能直接应用于localStorage，但你可以将token存储在一个HttpOnly的cookie中，然后在服务器端验证token。这样，即使网站受到XSS攻击，攻击者也无法通过JavaScript访问到cookie。