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

先区分仅主机与 Domain 作用域。Path 选择请求路径，不构成授权边界。Secure 限制传输，但不加密存储。SameSite 影响跨站上下文，现代浏览器的 None 还需要 Secure。HttpOnly 阻止 document.cookie 访问，但浏览器仍发送 Cookie。支持前缀的浏览器要求 __Host- 使用 Secure、无 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 或其他浏览器存储；避免增加站点并不需要的存储。

来源