Cookie安全属性：SameSite

一、背景

突然本地启动的应用通过公司SSO登录后依旧拿不到登录态信息，前两天还好好啊，排查发现保存登录态的cookie增加了Secure属性：

set-cookie: ticket=86A24; Max-Age=7775999; Domain=test.com; Path=/;HttpOnly; SameSite=None; Secure

咦？平台团队怎么突然加了Secure属性，并且SameSite=None;又是啥？

二、Cookie的SameSite属性

2.1 先弄清几个概念

同站（Same Site）和跨站（Cross Site）

同站： 顶级域名+1相同（即主域相同）的站点（跟端口无关），也叫本方（First-party）；
跨站：非同站，也叫第三方（Third-party）。

同源（Same Origin）和跨域（Cross Origin）

同源：协议（https?）+域名+端口 三者完全相同；
跨域：非同源。

跨站请求

首先要明白一个页面引用的外部资源（CSS，JS，图片以及通过JS API发送的请求等）可能来自不同的站点。

跟页面不是同站的请求都是跨站请求。如页面www.example.com/a里引用了图片www.baidu.com/image/dog.png，加载图片的请求就是跨站请求。

跨站请求概念是相对的，如图片www.baidu.com/image/dog.png在页面www.example.com/a里是跨站请求，但是在www.baidu.com/a页面里是同站请求。

2.2 干嘛的？

SameSite属性就是控制哪些跨站请求可以携带cookie。

1. 解决cookie信息泄露；
2. 防御CSRF攻击。

2.3 语法

SameSite=Strict/Lax/None

三种取值

1. Strict
   严格模式，必须同站请求才能发送cookie。
2. Lax (relax缩写)
   宽松模式，安全的跨站请求可以发送cookie。
3. None
   显示地禁止SameSite限制，必须配合Secure一起使用（浏览器最后的坚持）。

安全的跨站请求

比较难理解的就是Lax模式下浏览器视为哪些跨站请求时安全的：
总结下就是同步的GET请求
比如通过对 的点击，对

的GET方式提交，还有改变 location.href，调用 window.open() 等方式产生的请求

SameSite并不影响跨站请求的响应设置cookie。

2.4 怎么用？

首先看cookie怎么用的：

1. 对于只需要同站访问的cookie可以显示的指定SameSite=Lax/SameSite=Strict;
2. 对于跨站访问的cookie需要显示的指定SameSite=None; Secure；
3. 不要采用SameSite默认，跨浏览器的默认行为不一致。

三、再看开头提到的问题：

因为SSO登录态cookie需要被跨站访问，所以平台把登录态cookie设置成SameSite=None; Secure。因为本地开发时启动的应用是http协议的，所以无法拿到登录态cookie。

3.1 解决方案

在DevTool里手动把登录态Cookie的Secure属性删掉。

参考

整理自笔记Cookie SameSite=none