Cookie 作用域应比应用边界更窄

Mon, 15 Jun 2026 00:00:00 +0000

Cookie 依据浏览器规则附加到请求，而不是依据最初设置它的服务器组件。宽泛的 Domain 或 Path 会把状态暴露给无关的路由或子域名，而缺失传输与脚本限制则会放大其他失败造成的损害。

一起复核这些维度，同时区分发送目的地、JavaScript 访问权限与删除所针对的存储身份。

当省略 Domain 时，Cookie 被限定在设置它的主机内。加上 Domain=example.test 则它也允许发给符合条件子域名。只有多个主机确实共享同一应用与信任边界时才使用更宽的形式。

检视响应而不把真实 Cookie 值打进日志。头部名称不区分大小写，脱敏也必须覆盖 HTTP/2 风格的小写名称：

curl -sS -D - -o /dev/null https://app.example.test/login \
 | awk '
 tolower($0) ~ /^set-cookie:/ {
 sub(/^[^:]*:[^;]*/, "Set-Cookie: [value redacted]")
 print
 }
 '

一起复核这些属性

Secure 把 Cookie 传输限制在安全传输上，通常是 HTTPS；它不会加密存储的值。
HttpOnly 通过 document.cookie 阻止 JavaScript 访问；它不会阻止浏览器发送该 Cookie。
SameSite 影响跨站请求，必须匹配应用的导航或嵌入需求。
Path 控制发送时机，但它不是同一主机上不同应用之间的授权边界。

在现代浏览器中，SameSite=None 的 Cookie 还需要 Secure。避免把这对组合复制进不需要跨站用途的应用。

同站比同源更宽：使用 HTTPS 的兄弟子域名可以同站，同时仍属于不同源。因此，SameSite 不能替代主机边界或应用自身的 CSRF 防护。Cookie 也不按端口隔离，即便使用 __Host- 前缀也是如此。

在其约束契合时使用前缀

__Secure- 与 __Host- 等 Cookie 名称前缀，让支持的浏览器强制额外的要求。__Host- Cookie 必须使用 Secure、省略 Domain、并使用 Path=/，这使主机专用的意图变得显式。

用相同作用域测试删除

使用 Max-Age=0 或过去的 Expires 值，删除同名且域名/路径作用域相同的 Cookie；并非每个属性都参与存储身份。发送删除指令仍需满足前缀与安全来源要求。应保留最初是否省略 Domain 的选择：让仅主机 Cookie 过期时不要添加 Domain，并明确指定原来的 Path。当前 6265bis 草案把仅主机标记也纳入存储身份，因此只匹配界面显示的域名字符串，不足以构成可移植的删除方法。应在目标浏览器中验证删除结果。登出只清除一个作用域时，另一个可能仍然有效；服务器端会话或令牌也可能需要失效处理。

一个真正静态的文档站点通常没有理由设置应用 Cookie。检查有代表性的公共响应是否包含 Set-Cookie，并在导航后检视浏览器存储，包含第三方脚本的影响。单靠 curl 响应头检查发现不了 JavaScript 设置的 Cookie 或其他浏览器存储；避免增加站点并不需要的存储。

来源

RFC 6265 — HTTP State Management Mechanism，Cookie 存储与作用域，已核验 2026-10-15。
MDN: Set-Cookie，属性与名称前缀，已核验 2026-10-15。
HTTPWG Cookie 规范草案，SameSite 与 Cookie 前缀要求，已核验 2026-10-15。

Privacy · XB 现场笔记

Cookie 作用域应比应用边界更窄

偏好仅主机 Cookie

一起复核这些属性

在其约束契合时使用前缀

用相同作用域测试删除

让静态站点免 Cookie

来源