如果用 localstorage 替代 cookie 是不是就不存在 csrf 问题了？

[yodhcn]

如果用 localstorage 替代 cookie 是不是就不存在 csrf 问题了？

cookie 随请求自动携带的特性，是不是 csrf 问题的主要原因？

localstorage 存储 sessionId + 请求时通过 header 携带 sessionId 的这种方式，与传统的通过 cookie 存储与携带 sessionId 的方式相比，哪种方式更好？

[lianyue]

csrf 你不如需要安全操作的都是用 PUT PATCH DELETE 方法 HEAD GET POST 不允许用于安全的操作 更方便

[Puteulanus]

请求时通过 header 携带 sessionId ，意思是请求的时候用 JS 手动操作？那 sessionId 就必须在 JS 可操作的范围内，不像 HttpOnly 的 cookie ，那在 XSS 发生的时候会更危险

[akira]

有区别么，只要识别信息带过去了，就都一样

[beginor]

一个是浏览器行为，一个是 js 行为，不一样的。如果是 cookie 的话，浏览器自动按照地址发送 cookie ，而 local storage 里面的东西只能 js 主动发送，各有利弊

[Al0rid4l]

哪怕是 httponly 的 cookie, XSS 也是要防的, 还得防 CSRF, 存 Localstorage 好歹我只要防 XSS 就行, 我选 Localstorage, 当然如果要偷懒那就 cookie

[xqk111]

CSRF ，一般都是二次校验，苹果啊，支付啊，都是二次校验，加强安全性

[nothingistrue]

如果你的后台有分布式会话跟踪的需要，已经把 Session 改造成了 sessionId-redis 存储的形式，那么前端把 sessionId 的携带方式改造一下就没有问题。否则，就不要干这种杀鸡用牛刀的事，防 CSRF 很简单，不需要修改通用规范这么大的成本。

[coolzjy]

目前来看使用 JavaScript 手工管理凭据信息是更主流一些的方式：一来确实可以预防 CSRF ，更重要的是现代浏览器对于跨站 cookie 的限制越来越严格了，在跨域场景下使用 cookie 管理凭据已经基本不可行了。

[dode]

sessionId 就存在 cookie 里面的

[yuezk]

CSRF 的 token 和 sessionId 是两个东西，CSRF token 不需要长时间保存，最佳实践就是以 JS 变量或者隐藏字段的方式输出在页面中。

[yodhcn]

@nothingistrue 确实如此，虽然 spring-session 支持 HttpSessionStrategy ，但是又没有分布式的需求，引入 spring-session 就有点多余。

但如果是前后端分离，比如前端在 a.com ，后端在 b.com ，这种情况又该怎样预防 CSRF ？

[yodhcn]

@nothingistrue 如果你说的是 spring-session ，它也可以用 MapSessionRepository 存储 session

https://stackoverflow.com/questions/28384907/can-i-enable-just-spring-session-header-authentication