cookie 的 Secure 与 SameSite
Secure 与 SameSite 都不是服务端执行的检查。它们是用户代理在决定「要不要把这枚 Cookie 附到这条出站请求上」时遵循的指令，而服务端只能看到结果：要么有一个 Cookie 头，要么什么都没有。这种不对称正是它们存在的理由，也正是它们的陷阱。 两个标志位都很便宜，也都坏得很安静：缺了 Secure，一条明文请求路上的任何人都能拿走会话；SameSite 缺失或太松，状态变更请求就仍然能被另一个源触达；SameSite 太严，又会让单点登录赖以工作的跳转链路断掉。要选的，是你更愿意去排查哪一种。 Secure 挡住明文那一份 Secure 要求用户代理只把这枚 Cookie 附到 https 协议的请求上，于是一条明文请求——用户点开的 http:// 链接、HSTS 生效之前下发的跳转、混用的内容子资源——就不会带上会话令牌，路径上的旁观者无从读取。MDN 记下了那个例外：localhost 被视为可信，所以开发期 Secure Cookie 照样会走 http://localhost。实验从客户端这一侧把规则演示出来：一个存了五枚 Cookie 的 jar 在明文 http 上只发出三枚，把带 Secure 的两枚扣住；而协议一旦换成 https，五枚全部附上。 Secure 不做什么，同样值得说清。它不是存储规则——浏览器照样存下这枚 Cookie，稍后在 HTTPS 上发送。它不是完整性规则，也不能代替 HttpOnly，后者才是让 document.cookie 与 XSS 载荷读不到那个值的东西。它也救不了一条已经在明文上发出、Set-Cookie 头在途中被改写的响应；这正是为什么 Secure 应当与 HSTS、与整站跳转 HTTPS 一起上，而不是拿它顶替。 ...
