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

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

检视响应而不把真实 Cookie 值打进日志：

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

一起复核这些属性

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

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

在其约束契合时使用前缀

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

用相同作用域测试删除

删除 Cookie 需要一条与存储它所用属性匹配的过期指令，尤其是名称、域名与路径。只清除一个变体的登出可能让另一个 Cookie 仍然有效。

一个真正静态的文档站点通常没有理由设置应用 Cookie。核验公共响应不含 Set-Cookie 响应头，而不是为站点并不需要的存储增加一个同意界面。

来源