现在还有用 cookies 吗

修正一下题目吧：现在前后端分离的新项目中做身份验证，是使用cookie+(session id/token)，还是使用header+token比较流行

抱歉，没经过大脑思考就提出这样的问题，没想到引起这么大的反应，先给各位大佬道个歉, 占用公共资源了

提问方式确认有问题，这两个确实不能一概而论。一个是传输存储方式，一个是实现方案

其实想表达的是，web开发中身份验证方式，是使用header 加个token 头的方式比较流行还是直接通过cookie+(session id / token)方式管理比较流行

今天也被公司项目的cookie校验身份的一个bug整迷糊了（不是简单的校验cookie中的session id就可以了），以往都是直接对header 中的token就可以了。这种傻逼题目是在一脑子浆糊的情况下提出来的，见谅（已经跪下了）

以往开发的项目，都是前后端分离的或者是面向app的，使用header+token的方式做身份校验。前端把token信息保存在localstorage中（今天了解过后才发现localstorage是不能跨域的，子域也不行，以往的前端也确实是spa, 所以当web是非spa应用时，应该就只能选cookie了）

在我看来：

使用cookie+(session id/token)

优点：

• 各种标准/代码库比较完善，浏览器支持也比较到位
• 在加上了httpOnly和适当的跨域头等，保证安全方面机制比较完善，说不安全是我没经过大脑思考说出来的（一鞠躬），只是现在的项目在这两方面都有所欠缺

缺点：

• 只能在web中使用，如果终端包含了浏览器和客户端，客户端就又要实现一套身份校验逻辑（应该不会有人在app中请求http在header里加一个cookie 头吧）
• 如果只是传输身份认证token信息（或者sessin id），传输量不是很大，没什么问题；但如果不加管理，往里面保存一些用户其他的信息，就容易导致cookie增大，每次传输的包体就会增大
• 可能导致csrf，需要在页面中加入额外的随机数做处理，不过加入随机数校验处理后也能一定程度上解决防重放攻击
• cookie中包含了key: value: age, domain, path；当key相同，domain不同，那可能导致一些血与泪的教训（躺过）

使用header+token

优点：

• 如果终端包含了浏览器和客户端，校验逻辑可以统一，各端沟通成本降低
• 由于身份信息保存在localstorage中，所以无需担心csrf
• 调试成本底，http中有没有传Authorization头一眼看穿，你就算有多个也很容易看出来；cookie头通常包含很多信息，数据一多眼睛就晕（个人觉得）

缺点：

• 非spa应用无法使用（粗略认识）
• 没有cookie+sessions id 来的直接粗暴

至于xss，防范的手段还是在于网页的数据渲染上，只能靠过滤特殊字符实现，无论是localstorage还是cookie，只要注入了脚本，都是不安全的

如果给我选：

if spa {
    chose Authorization header
}else {
    chose cookie(session id /token) + httpOnly + 随机数
}

希望技术问题就事论事