摘要

  • draft-ietf-httpbis-layered-cookies-02 把 Expires 与 Max-Age 定义为 Cookie 的最长寿命；用户代理可以因配额、内存、隐私或用户操作提前逐出。
  • 客户端缺少 Cookie 不能单独证明注销或服务端撤销，客户端仍有 Cookie 也不能证明服务端会话有效。存储生命周期与授权生命周期必须分别记账。

审计系统发现会话 Cookie 比预定到期时间早了三天消失，于是把事件标成“服务端强制注销”。服务端会话账本没有撤销记录，身份团队开始追查异常操作。

后来发现，浏览器在主机 Cookie 数量超过限制后逐出了较早访问的条目。Cookie 的到期上限没有被违反；错误来自把上限当成保留担保。

《Cookies: HTTP State Management Mechanism》02 版于 2026 年 5 月 21 日作为 IETF HTTP 工作组的活跃 Internet-Draft 发布，预定于 2026 年 11 月 22 日到期。它以标准轨道为目标，并称若获批准将取代 RFC 6265 与 6265bis。当前仍是工作文件，不是 RFC、浏览器一致性报告或部署证据。

两个生命周期没有同一个所有者

服务器通过 Set-Cookie 提供名称、值和属性；用户代理决定是否接受、保存、逐出以及后来是否发送。服务端则维护会话记录、轮换、撤销、主体映射和权限。

Expires 与 Max-Age 只给客户端状态设定最长寿命。草案明确说明，用户代理无需一直保留到该时刻，可以因内存压力、配额、隐私或用户删除而提前清除。

因此，客户端缺失只证明在观察时没有发送或没有保存该值。它没有说明是谁触发了清除，也没有说明服务端账本发生什么。

反过来，客户端仍持有值，也不证明会话仍然有效。服务器可能已撤销、轮换或拒绝它。成熟系统把客户端存储与服务端权力分成两条状态线。

删除动作也需要精确作用域

服务器常用过去的到期时间删除 Cookie。但删除成功要求响应中的 Path 与 Domain 匹配原有条目。名称相同并不足够。

如果注销端点用 Path=/ 删除，而另一个敏感条目位于不同 Path 或 Domain 组合，浏览器可以保留后者。界面显示“退出成功”，并不证明每个客户端状态都被删除。

更重要的是，安全注销不能只依赖客户端删除。服务器应先使会话权力失效，再发送覆盖所有已知作用域的清除指令，并在后续使用时拒绝旧值。

这形成三个回执：服务端撤销、客户端清除尝试、后续拒绝验证。Set-Cookie 200 响应只是第二类动作的一部分。

Secure 不是来源签名

Secure 约束用户代理只在安全通道上发送 Cookie，通常是 HTTP over TLS。它对防止普通明文传输很重要。

TLS 保护这次连接，不重建存储值的历史。一个兄弟子域可能设置更宽的 Domain Cookie；同名 Cookie 可能有多个 Path；服务端会话可能早已无效。安全通道不能回答这些问题。

草案还保留历史警告：在 Cookie 协议的主动攻击模型下，Secure 本身不能提供完整完整性。无论具体实现如何，证据边界都一样——通道保护不能代替 Cookie 来源与服务器状态验证。

服务端必须验证值的结构或签名、预期受众、会话状态、主体和本次操作权限。收到值不是完成认证。

Domain、Path 与端口并非同一安全坐标

不带 Domain 的 Cookie 只发回原主机；带 Domain 的 Cookie 可覆盖相应子域。公共后缀规则阻止越过注册边界，却不会让兄弟应用自动互信。

一个兄弟主机可以设置父域 Cookie，使另一个兄弟收到。接收方最坏情况下无法区分该值与自己设置的值。Domain 表达配送范围，不是作者证明。

Path 决定何时发送，但不提供完整性隔离；一个路径的响应可以给另一路径设置状态。端口同样不隔离 Cookie，即使 Web Origin 模型通常把端口作为坐标。

所以不能在同一主机的不同路径或端口部署互不信任服务，然后让 Cookie 独自承担隔离。需要主机边界和服务器端上下文绑定。

HttpOnly、SameSite 与前缀各管一件事

HttpOnly 限制 JavaScript 等非 HTTP API 直接读取，不能证明设置者，也不能防止浏览器自动附带。

SameSite 改变跨站上下文中的发送条件，可以缓解部分 CSRF 路径，但不证明真人意图、身份或授权。

__Secure- 与 __Host- 前缀增加接受条件，能缩小注入与作用域错误。它们仍然只是客户端接受规则，不会替服务端签署会话有效与业务批准。

多个绿色属性叠加后仍应逐项说明控制对象与残余风险。把它们合成“安全 Cookie”标签，会把细节重新隐藏。

环境权限会先于用户意图到达

浏览器会自动把符合规则的 Cookie 附加到请求。远程一方即使不知道值，也可能通过表单、重定向或其他方式指定目标 URL，让浏览器携带权力。

服务器若只看 Cookie，就可能把浏览器自动提供的会话误读为用户主动批准。这是环境权限与混淆代理问题的核心。

敏感操作需要另外绑定意图：防 CSRF 材料、来源检查、新鲜度、确认或等效机制。随后还需要服务端授权与提交回执。

Cookie 头只能支持一个窄结论：用户代理按当前规则选择并发送了这些值。它不签署真人意图。

同名值与顺序也会制造伪权力

Cookie 名称区分大小写；仅大小写不同的两个名称可以共存。同名 Cookie 也可能因不同 Path 或创建信息同时进入请求。

服务器不应依赖序列化顺序来选择权威值。字符串解析器若永远取第一个，实际上在协议没有授予顺序权力的地方自创优先级。

审计应保留重复名称、大小写、作用域与解析结果，而不是只记录最终选中的值。原始秘密不能写入日志，但结构歧义必须可见。

真正的权威来自服务端验证策略，而不是头字段中的位置。

来源与限制

冻结资料包括 02 版草案、Datatracker、HTTP 工作组、RFC 6265 与 6265bis、HTTP、TLS 1.3、WHATWG Origin/URL、IANA 字段注册表和 Public Suffix List。

它们证明规范文本与官方记录，不证明某浏览器一致性、真实入侵或具体服务行为。开头的提前逐出是构造案例。

来源