现在还有用 cookies 吗

[pabno]

接手公司的老项目，很多安全和身份相关的功能都是用 cookies 实现的。这玩意儿感觉既不好测试又不安全，以往都是使用 token 来做的身份安全相关

不知道现在在 web 端主流是用 cookies 还是 token ？

修正一下题目吧：现在前后端分离的新项目中做身份验证，是使用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 + 随机数
}

希望技术问题就事论事

[poic]

你不存 token ？

[monsterxx03]

所以你 web 上 token 存哪的?

[lxk11153]

cookies 哪里不安全？

[ChanKc]

我宁愿用 Cookie 。现有的库，包，整个的机制都很完善了，现成方案多，工作量少

[lxk11153]

fix #3 弱弱问下: cookies 哪里不安全？

[imnpc]

session + cookies 里面难道没带安全验证吗？
token 的一般用在前后端分离的多

[beldon]

token 就一定安全了？

[chendy]

cookie 哪里不安全？
cookie 的优点是浏览器自动处理，缺点是只能在浏览器里用，哪里有什么安全问题？

[imdong]

不应该很多都是 session 的方式？

然后 session_id / token 使用 cookies 或者 其他方式 存起来而已。

但是依然有将一些 加密后的数据使用 cookie 存在客户端。

[GM]

因为 cookies 里存 sessionId 不安全，所以我选择了 cookieless 方案，把 sessionId 放在 url 上了，这下安全多了

骄傲的狗脸.jpg

[sunjourney]

你的应用都是单页的？你的 token 放哪？你的图片鉴权是怎么做的？

[sunjourney]

为啥全 token 和 cookie 对比？你喜欢吃苹果还是饼干？

[ChanKc]

@sunjourney 我猜是 custom HTTP header，请求得到的图片的 base64 什么的再用 blob 吧

[sunjourney]

@ChanKc #13 那也是很厉害了，expiration 、cache 啥的自己实现一套？看来题主是个大佬

[reus]

token 就是存 cookie 里的
连这都不知道，都可以做那么多年开发，可见这行门槛之低

[HUALIAN]

阿里京东腾讯都用 cookie，安全得很

[ChanKc]

@sunjourney 是的

[ChanKc]

@sunjourney 手头上有个项目就因为这么一套搞得有个 expiration 的 bug…

[renmu123]

其实 cookie 应该比 token 安全，起码 token 没办法原生实现失效

[sunjourney]

@ChanKc #18 gzip 啥的呢，如果是大图，体验怎么样？

[elevioux]

token 和 cookie 没有本质的区别。

即使你不用 cookie 那套，自己实现管理 token，这个 token 不一样也要存客户端？

国内的京东、淘宝不一样用 cookie 用的挺欢？

[ChanKc]

@sunjourney gzip 没有
反正我做前端，接口也是后端定
正好借此机会体验了一把 lazyload+IntersectionObserver+service worker+cache API，可以说很好地丰富了简历了

[kop1989]

cookie 是一种存储介质，token 指的是令牌。
楼上讨论的这么欢？

[sunjourney]

@ChanKc #22 这种瞎搞的搞法，感觉并不能加分，有什么好处吗？总不能简历里都是反标准、负收益的东西吧？

[ochatokori]

？
token 存 localstorage 或者 indexeddb 不行吗

[sunjourney]

@ChanKc #22 只能说当玩具练练手比较好

[iX8NEGGn]

session cookies 傻傻分不清

[ChanKc]

其实默认情况下，用 custom http header 是比用 cookie （不开 same site 不开 secure 不开 HTTP only ）要安全一些，因为只有同域的 ajax 才能用 custom http header 。
要是 token 放 cookie 里…

[OhYee]

不存 cookie 的话，只能存 localStorage 了吧，不过这两者在安全上没啥区别吧

另外 cookie 好像不带 s，有大佬讲一下应该拼 cookie 还是 cookies 么？

[ChanKc]

@sunjourney 现在很多时候面试啊简历啊都是反标准负收益的东西
我前一阵面试某大厂，问 get 和 post 什么区别，我就按 RFC 标准的答了
面试官问“要是后端不按标准来写呢”
而且这种事情，肯定不会写“我都是因为后端不标准所以我做的这些优化”

[Jirajine]

你喝水的时候是用杯子还是水？

[lanbatian]

今天才改了一个由于 cookie 过期导致的 bug

[belin520]

技术论坛一聊七七八八的话题就进水深火热，一聊技术话题就蹦了

[tlday]

我很好奇问出这样问题的人的提问背景。看了楼主的发帖记录，看起来我们对“多年 Java 狗”的理解有点分歧...

[also24]

@ChanKc #28
token 存哪里呢？存在 localStorage 的话，遇到了 XSS，卒……

还不如存 Cookie 里，起码可以用 HttpOnly 来保护一下……

[wangxiaoaer]

@chendy #8 除了浏览器，服务端、客户端也能用啊，以 java 为例，很多库都支持 cookie 的。

[sunjourney]

@ChanKc #30 我会建议后端改成标准

[ChanKc]

@also24 xss 时我都可以直接利用 cookie 了…还会在乎读 cookie 的值吗…

[also24]

@ChanKc #38
肯定会啊。。。你直接利用 Cookie 的话，利用脚本必须放在你的 xss 脚本里的嘛。
而且必须用户主动运行你的 XSS 脚本才能执行利用脚本，执行次数很有限嘛。

如果不加 HttpOnly，我 XSS 直接偷你的 Cookie 丢出来，我在外面想怎么用怎么用，多方便。

and 其实搜一下 " XSS 窃取 Cookie " 就能找到很多例子……

[sunjourney]

@ChanKc #38 cookie 有 secure 的，xss 读不到

[ChanKc]

@also24 可以，受教了
所以就是同样受害，影响范围不一样是吧

[yhxx]

cookie 和 token 有啥关系，没太懂

[also24]

@ChanKc #41
恩，并不是防止攻击，只是控制损失，其实我觉得这也算是使用 Cookie 来存储凭据的一部分优势。

顺便说一下：
我并不是拥护 Cookie，Cookie 机制也有很多劣势（例如无脑带 Cookie 导致无关请求的体积增大）；
只是说在 『限制 JS 读取凭据』这件事上，Cookie 有一定的优势。

[butterf1y]

token 不就是个约定俗成的名吗？和 cookie 有关系？

[Felldeadbird]

cookie 哪里不安全了。token 被人知道了，在有效期内，你没做唯一客户端校验，不一样风险吗？

[cheeto]

🎣？

[littleylv]

楼主确定不是来🎣的？

[wangritian]

楼主看一眼 http 的报文，uri/body/header/cookie 这些东西只是划分内容的标记，保证安全需要的是策略和算法
想起面试时经常问 get/post 有什么区别，很多小伙伴答 post 更安全

[limuyan44]

这不是个技术论坛吗？你们还能讨论用 cookie 还是 token 这么火热的。

[misaka19000]

V 站这种提奇葩问题的奇葩楼主越来越多了，已经让人搞不懂是为了钓鱼还是真的太菜了

[ArianX]

你是说把 token 放在 header 里和放在 cookie 里的区别？

[love]

@ochatokori 存在这种本地存储才不安全

[vone]

前端程序员果然垃圾

[murmur]

@wangritian post 的却略微安全一点，可以避免用户把整个链接复制给别人的时候带上一些奇奇怪怪的东西

[daimubai]

楼主想说的是将 token 放在 Header 中吧，我们之前的前端主要是 App，采用的这种方式。

如果是 B/S 的话，通常做法是把 token 放在 cookies 中吧

[daimubai]

楼主想说的是将 token 放在 Header 中吧，我们之前的前端主要是原生 App，采用的这种方式。

如果是 B/S 的话，通常做法是把 token 放在 cookies 中吧

[Erroad]

你给我解释解释什么叫做 token ？
我问你什么叫做 token?

[madNeal]

@also24 httponly 的本质是限制 js 无法操作 cookie

[also24]

@madNeal #58
对啊，这不就是我要表达的意思么？

放进 localStorage 的话，XSS 脚本就能获取到（然后发送出去）；
放加了 HttpOnly 的 Cookie 里面，XSS 脚本获取不到了，于是就不会有（能发出去）这个问题。

[takemeaway]

本来看到这种问题我就很无语，后来看到一部分回答，更无语。。。

麻烦大家提高一点专业素质，真当码农是农民呢。

[wolfan]

现在对 cookie 的权限要求好像是最严的，所以这么安全的地方不用来存点重要的东西，难道浪费掉？

[tlday]

@vone 这关前端程序员什么事？楼主一个做 Java 和 Go 的，也成前端程序员了？况且一个孤例打翻一船人？这年头一线程序狗的大部分工作不是 CRUD 就是切图再不济就是调个参，都是无产阶级，还搞出优越感鄙视链了？

[loading]

建议楼主多学习，你这样很不安全。

[tlday]

@vone 看了你的回帖记录，话都不会说，又是“儿子”又是“你🐎”的。block 了。

[guanhui07]

token 存 localstorage cookie 都可 ，token 也可以做成 jwt 这么服务器也可以做成服务器存储以及不存储 验证，session 基础于 cookie，session 在服务器有存储验证，现在前端登录就这几种吧，还有第三方登录，sso

[wangritian]

@murmur 小伙伴一般只说 post 的内容是看不见的[doge]，这些人无论做前端还是后端，天天收发 http 请求，我怀疑一眼报文格式都没看过

[lzk50136]

基础不扎实。。。先多了解一下基础知识先吧。。。楼上的都吵翻天了。

[libook]

不管用啥，最重要的是防止凭据被伪造，不加密、弱加密不管用什么技术都有安全风险。

Token 的优势在于不依赖浏览器标准，任何非浏览器客户端也可以轻松使用，比如 App 端，处理 Cookie 的时候复杂度往往比较高，用 token 简单明了。

Cookie 的优势在于有浏览器标准的支持，很多功能不需要自己实现，只要浏览器按照标准设计，就能直接使用 Cookie 的特性。

Token 本身不包括存储技术，客户端希望保持会话的话是需要自己提供机制来存储 Token 的，在浏览器端可以用 Web Storage 来存储，在 App 端可以直接存在本地数据库或文件里。

传输方式上：Cookie 是封装好的、在 Header 里传输的方式； Token 可以自己封装用 Header 里的某字段来传，也可以直接在 URL 里传，比较灵活。

然后因为 Cookie 广泛用于用户数据追踪的技术，所以国际上通常要求在用户同意的情况下使用 Cookie 。

[telung]

你公司的老项目要给你这个菜鸡玩完了

[Torpedo]

哪个网站不用 cookie 。。。

[mxT52CRuqR6o5]

多看看标准，别自己重新实现一套标准里有的东西做的结果还没标准安全

[aimsam]

token 和 cookie 不是一个东西怎么比？楼主问的应该是 localStorage 和 cookie 用哪个。localStorage 还是有一些局限的。做安全还是 cookie 好用。

[lululau]

token in http header 可以不用考虑 CSRF protection，不好的地方目前遇到过的是下载文件需要用 blob API，文件太大的话有问题

[ychost]

cookie 蛮好的，至少代码干净

[inktiger]

token 还是要依托 cookies 吧，不然存哪呢，浏览器本地储存？

[longjiahui]

cookie!!!!!!!!!

[karnaugh]

@ochatokori ie7 表示不认识这俩东西（滑稽

[kayv]

用 httponly cookie 很安全

[pabno]

@libook 赞同你的观点，我题目描述的也是有问题。在我的观点来看：如果一项技术需要很多其他的措施来实现安全性（比如 cookie 预防 csrf 需要增加额外随机数校验），那么他的安全性获取是不便利的，可能我比较懒

[pabno]

@ChanKc 前端不知道，后端基于 Authorization header 的身份验证机制其实库也挺全的，spring boot+security 其实也是几行配置的事情

[pabno]

@daimubai 是的，我表述不太对。以往的项目都是 spa 应用，加上有 app，所以都是采用 Authorization header 的方式，感觉用起来挺舒服的，今天才知道 localstore 是不能跨子域名的

[laike9m]

@kop1989 #21 233

[ChanKc]

@pabno Authorization 也是标准的 header 了，这个前端也是比较好做的，不过存储的问题还是有

[ChanKc]

@pabno 不能跨域其实是个好东西。local storage 不能跨域是对的，要不然别的网站脚本都能读你的网站的存储了。cookie 也是可以做到不跨域的，SameSite 了解一下。

[xuanbg]

和 cookie 对标的怎么成了 token ？难道不应该是 localstore 吗？和 token 相同功用的是 session 好不好……

做前端这都搞不清，果然是娱乐圈……

[iyangyuan]

两者既没有本质区别，又不是一回事

[ChanKc]

cookie 跨域了所以会容易 csrf 啊

[xuanbg]

@inktiger token 不需要存储啊，放内存里面就挺好。

[ChanKc]

@xuanbg 页面一关就失效，同域名多标签页就失效

[iyu90]

@xuanbg 他是 java 狗，前端莫名其妙躺枪

[xuanbg]

@ChanKc 一般用 token 的都是后台管理应用，spa 就行。这些问题也就不存在啦。

[sampeng]

我最没力吐槽的就是说的 cookie 的缺陷。做服务端的都不认为是缺点。
你要是专职前端我也要一条一条反驳：
1，谁告诉你只有 web 和浏览器支持？ app 不支持数据写 app 的不懂 cookie，只知道依葫芦画瓢用 token 。所有 http client 都留了一个客户端的 cookie store 接口是为啥的？只是很少有人注意和实现
2，不要把客户端和服务端要保存的状态混为一谈。服务端最多要存个 session id 。其他你说的都是傻子才用 cookie 传。这条根本不成立
3，cookie 导致 crsf ？ wtf ？说的好像放参数和 header 就不行了。crsf 归根结底是服务端设计消息传递和状态传递不严谨。放 header 会更简单…
4，不要自己不懂就说是缺点。血泪教训是你不懂导致的。我不会开飞机是不是也成了缺点呢？有时间吐槽所谓血泪教训，为什么不去看看 cookie 得完整 rfc ？

另外说一点，鉴于你说的这么肤浅，估计你都没考虑过，token 放 header 传输真心是 app 整出来的复合 http 认真协议。但是浏览器上一旦发生跨域请求的时候，如果服务端不做额外设置，浏览器无论如何会发两次请求，一次 option，请求询问是否可以用这个 header 头。

[youxiachai]

app 请求 header 带 cookie 不是蛮普遍的吗.....为啥不会用...很好奇.lz 怎么想的...

[youxiachai]

@vone lz 是学 java 的,你喷歪了...

[youxiachai]

老实说..一个做后端的..不认真看一遍 RFC 标准.....不知道怎么吐槽..

[chairuosen]

cookie 不符合后端只负责 api 服务的前后分离的职责设计，属于为前后不分离时期制定的标准，同理还有 301/302 Location 字段。

前后分离的设计，传输接口只有内容，没有行为，行为完全由前端控制，Set-Cookie Location 等带有行为的 http header 就不应该出现。

[ChanKc]

@sampeng 我有些问题想请教
csrf 归根结底是服务端设计消息传递和状态传递不严谨，这个怎么说
另外你说的 Option 请求应该是 CORS-preflight request 吧。我感觉这个不是每次都会发生的，因为可以用 CORS-preflight cache 此外还有 use-CORS-preflight flag form 表单跨域的时候好像也不会请求

[ChanKc]

@xuanbg 公司有些内部系统就是这样的，我总是习惯鼠标滚轮按下去在新标签页打开，因为有时候喜欢切换着不同标签页看。每次都不行，非常难受

[OHyn]

cookie 好用，但是写 cookie 的时候要注意一下 sameSite 的配置问题，chrome > 80 的版本，没带 sameSite = none 的话跨站请求带 cookie 会被拦截掉，这个还要添加 Secure 。还有某些老版本浏览器下 sameSite = none 会被识别成 Strict，要检查一下 userAgent，浏览器兼容性问题终于能折磨后端了。

[EminemW]

我理解的 cookie 只是前端 存东西的地方。。token 是 session 的一种实现方式。。 不知道有没有错