摘要

  • RFC 10025 规定用户代理如何在特定条件下保存并返回 Cookie 状态。Cookie 值的业务含义、会话是否仍被接受，仍由应用决定。
  • Domain、路径、Secure、HttpOnly、SameSite 及 __Secure-、__Host- 前缀各自收窄一类边界；它们不证明请求有当前意图、已获许可或已经产生结果。
  • 可追溯的服务必须分别保存会话签发与撤销、请求上下文、动作授权、时效或重放判定、提交和外部结果，不能让 Cookie 一次跨越所有层次。

某个账户的收款对象被改动后，调查人员打开日志：请求来自已登录会话，Cookie 与账号匹配，服务返回 200。若此时报告写下“用户已认证，因此改动有效”，它没有解释事件，而是把五个未验证的判断藏进了一个熟悉的词。

Cookie 匹配只说明浏览器将一个状态值放入了这次请求，并且服务端按自身规则把它关联到了某个会话。它既不是对键盘前那个人的识别，也不是对动作本身的授权，更不是对下游资金、设备或数据状态的事实确认。把中间的传递信号写成最后的决定，是环境式权限最常见的放大方式。

RFC 10025 的克制恰好提供了修正。它定义 Set-Cookie 和 Cookie 字段，描述用户代理的存储、选择和返回。它不赋予 cookie-value 一个统一业务语义。这个值可以引用服务端会话、购物车、偏好或已失效的令牌；协议不替应用解释它。应用也就不能借协议的名义，把“值出现”扩展为“主体有授权”。

浏览器的范围决定了什么

一个 Cookie 由名称和值及若干属性组成：到期时间、域、路径、host-only、仅安全连接、仅 HTTP 接口和 same-site 状态。用户代理可以忽略接收到的 Cookie，也可在之后依策略或容量限制将其清除。服务端发出的不是一条永远被执行的命令，而是一份交给浏览器处理的指令。

省略 Domain 的 Cookie 是 host-only；可接受的 Domain 会使其在匹配的域范围内被选择。公共后缀处理可拦截某些过宽的 Domain。它们回答的是“浏览器可向哪里带上此值”，而不是“哪些系统有权用这个会话改变这项业务”。域边界不是组织授权图；同一可匹配范围内的主机也不因此共享对账户、资金或权限的决定权。

路径同样只是选择机制，不是保密隔离或授权规则。同名 Cookie 可能同时相关，服务端必须明确处理哪个值、为何接受、冲突时如何拒绝。把关键身份判定交给字段顺序，是把政策藏在一个无法审计的解析细节中。

Secure 把返回限制在用户代理认定的安全连接上；HttpOnly 限制非 HTTP API 的访问。这两项都应被认真部署，却不应被误读。Secure 不证明会话未被撤销，也不说明一次收款对象变更被允许。HttpOnly 并不妨碍浏览器在可用的 HTTP 请求中自动附带 Cookie。脚本读不到，并不意味着浏览器不会替它发送。

这正是 RFC 10025 所称的 ambient authority：第三方可让已经保存状态的浏览器，向某个资源发送带凭据性质的数据。风险不一定是秘密被复制；也可能是应用把自动携带的状态误作一项主动决定。

SameSite 不是意图证明

Strict 与 Lax 会改变跨站场景中 Cookie 被取回的条件，因而是有价值的缓解措施。然而 RFC 10025 将 Lax 描述为对某些 CSRF 攻击的纵深防御，而非稳健、通用的 CSRF 防御；默认模式的兼容行为还可能允许刚设置不久的 Cookie 出现在顶层的不安全方法导航中。

因此设计问题不该是“有 SameSite 吗”，而应是“这个动作除了会话外还需要什么证据”。变更恢复邮箱、导出客户数据、修改路由、支付或关闭账户，可能分别要求与页面绑定的防伪材料、来源上下文、近期重新认证、限额、冷静期、二人复核或异常审查。这些不是 Cookie 属性能够代替的配置；它们是业务层为后果承担责任的选择。

前缀把这条界线说得更清楚。__Secure- 要求安全来源和 Secure；__Host- 还要求 Path=/ 且不得有 Domain。它们能使某类错误签发在浏览器存储前被拒绝。它们不会查询服务器中的会话撤销状态，不会判断角色刚刚变化，也不会确认审批人是否同意。前缀之所以可信，正是因为它没有假装承担这些职责。

会话接受必须是实时的服务器决定

请求抵达后，服务器要回答的首先不是“这个 Cookie 像不像我发过的”，而是“它此刻选择的会话是否仍可被这个路由、这个账户状态和这个风险条件接受”。会话可能到期、显式注销、在密码重置后被替换、因恢复流程而受限，或因风险信号被拒绝。浏览器仍保存这个值，并不能推翻服务器的否决。

会话固定展示了真正的修复方向。问题不是登录前存在 Cookie；问题在于应用让同一标识在权限跃迁后继续生效，而未轮换、未重新判断。可验证的修复证据是签发、轮换、旧值失效和其后的拒绝，而不是事后从请求头里再读一遍字符串。

会话有效后，授权才开始。能浏览账户页面不等于能改受益人、添加管理员、导出资料或发布密钥。每个动作要看目标对象、当前角色、限额、授权范围、最近认证、二次确认及时间条件。HTTP 方法的“安全”或“幂等”描述协议语义，不是企业授权或真实世界结果的证明。

提交与结果也要分开。一份成功响应可能代表服务收到命令、内部事务已提交，或任务已排队；它不自动代表邮件送达、支付结算、设备完成配置或外部系统完成同步。高后果操作必须有可关联的动作标识、下游引用和结果观察，才不会把网页响应误写成事件结局。

让每层事实保留自己的证据

签发时，记录安全的会话引用、关联主体、前置认证或恢复事件、范围属性、轮换和撤销条件。接收时，记录接受 Cookie 的主机与路由、选中的会话引用、请求上下文检查及拒绝原因。决策时，记录请求动作、目标、适用规则、授权主体、必要的额外确认和时间。效果阶段，记录尝试、提交状态、下游参考、观察到的结果与补救路径。

这不是要求把普通浏览做成多重审批。它要求每一层只能证明自己看得见的事实。低风险读取可以很快；不可逆动作则必须能回答：谁在何时以什么条件允许了它，系统随后实际观察到什么。

来源