Cookie

Secure、HttpOnly 和 SameSite 分别描述支持这些规则的浏览器如何限制 Cookie。服务端收到的是最终的名称与值，而不是一张证明这些限制已经执行的证书。浏览器行为与服务端授权必须分开：Cookie 完全可能被正确发送，但当前请求的业务动作仍然不被允许，不能把出现 Cookie 头当成全部安全条件已经满足。 分开看设置、发送与脚本读取 Secure 限制 Cookie 通过安全连接发送，通常就是 HTTPS。现代浏览器 Cookie 规则还会拒绝从不安全语境设置 Secure Cookie；localhost 等开发例外应在目标浏览器中核对，而不能推广为任意明文主机都可信。这不仅是发送阶段的标记。一次 HTTPS 重定向无法撤回此前明文请求已经泄露的令牌，因此应结合 HTTPS 与适当的 HSTS 策略，而不是让两者互相替代。 HttpOnly 阻止通过 document.cookie 等非 HTTP 脚本接口读取 Cookie，但不会禁止浏览器把它附到符合条件的脚本请求上。被注入的同源 JavaScript 即使读不到令牌，也仍可能以用户身份发起操作。因此必须单独预防和限制 XSS；HttpOnly 减少的是其中一条窃取路径，并不是把脚本注入漏洞消除了。 SameSite 增加请求语境限制。Strict 通常允许同站请求，Lax 还允许使用安全方法的跨站顶层导航。显式 Lax 不会仅因为某次跨站 POST 是从顶层页面发起，就让 Cookie 自动附上。None 去掉这一项限制，但在支持规则的浏览器中必须搭配 Secure。第三方 Cookie 阻止、存储分区以及 Fetch 的凭据模式，仍可能阻止发送，不能把 None 理解成任何请求都无条件携带。 ...

Cookie 的主机与路径作用域，决定哪些目的地有资格收到它的名称和值。缩小这个集合有助于减少暴露，但作用域不是授权，而且 Cookie 并不采用浏览器完整的源边界。本文重点讨论 Domain 与 Path；传输方式、请求语境和浏览器策略还会增加其他限制，不能只凭一个属性就推断最终发送结果。 这里只展示发送资格，不代表授权或最终一定发送。公共后缀及其他 Cookie 规则仍适用；Path 和端口不隔离不可信应用。图示不宣称浏览器一致性验证。 Domain 选择主机，不隔离端口 省略 Domain 会建立 host-only Cookie。从 app.example.com 设置的 Cookie 只匹配这个主机，不匹配 shop.example.com。加入 Domain=example.com，则允许父域与匹配的子域收到它，但仍受其他 Cookie 条件约束。属性处理会忽略一个前导点，它并不是另一种通配符功能。只有那些更宽的接收方确实需要这个值，才应扩大作用域。 ...