Secure Cookie 标志.

Set-Cookie 响应头中的 Secure 属性将 Cookie 限定在加密连接上传输:浏览器绝不会通过明文 HTTP 发送该 Cookie,从而封堵经典的截获路径——在路径上的攻击者嗅探会话 Cookie,或强迫受害者访问某个 http:// 子资源以使其泄露。历史上,这类问题曾造就了"侧劫持(sidejacking)"——2010 年的 Firesheep Firefox 扩展之所以能在开放 Wi-Fi 上轻而易举地劫持 Facebook 和 Twitter 会话,正是因为那些 Cookie 缺少 Secure,此事推动整个行业转向全站 HTTPS。

仅有 Secure 还不够:能够在 HTTP 上注入的攻击者仍可覆写一个安全 Cookie(即"Cookie 抛掷(cookie tossing)"/固定攻击)。为此,RFC 6265bis 定义了两个用于加固的前缀。名为 __Secure-* 的 Cookie 必须携带 Secure 并从 HTTPS 源设置;__Host-* 前缀的 Cookie 还必须额外省略 Domain 并设置 Path=/,从而将其固定到确切的主机,阻断基于子域的注入。浏览器会静默拒绝任何违反这些规则的带前缀 Cookie。应将 Secure 与 HttpOnly、SameSite、收紧的作用域以及全站 HSTS 结合使用。需要注意的是,PortSwigger 于 2025 年的"Cookie Chaos"研究表明,解析器的怪异行为在某些技术栈中仍可绕过前缀强制——纵深防御依然不可或缺。

flowchart TD
  A[服务器设置 Cookie] --> B{是否有 Secure 属性?}
  B -->|否| C[通过 HTTP 与 HTTPS 发送<br/>在链路上可被嗅探]
  B -->|是| D{请求协议方案?}
  D -->|https://| E[发送 Cookie]
  D -->|http://| F[不发送 Cookie]
  E --> G{名称前缀?}
  G -->|__Host-| H[要求 Secure、无 Domain、<br/>Path=/ - 固定到主机]
  G -->|__Secure-| I[要求 Secure +<br/>HTTPS 源]
  G -->|无| J[可通过<br/>HTTP 注入被覆写]