Cookie名称前缀__Host-和__Secure-：浏览器接受条件怎么核对

如果你在Set-Cookie里看到以__Host-或__Secure-开头的Cookie名称，先要弄清它们各自被接受的条件。按MDN的说明，__Host-前缀要求Cookie同时满足四项：用Secure属性标记、从安全来源发送、不包含Domain属性、Path属性设置为/。__Secure-前缀的要求只有两项：用Secure属性标记、从安全来源发送。

所以核对顺序可以这样定：先看名称带哪个前缀，再按该前缀的条件逐项检查。__Host-的条件更严，多出“不带Domain”和“Path为/”两条。

一个自建情境（示例，不是对某个真实网站的记录）：你在练习目录里维护一个自建页面，用本地或公开的HTTPS地址打开它，在开发者工具的Network面板里查看响应头中的Set-Cookie行。下面所有Cookie名称和值都是练习用的自建数据。

适用范围：本文只讲这两个前缀各自要求Secure、来源安全、Domain与Path的条件，以及不符合时浏览器会拒绝。不讲会话固定攻击细节，不讲SameSite。

两个前缀都要求Secure属性，也都要求从安全来源发送。这两条是共同门槛，先核对它们，再看__Host-多出的两条。

按MDN对Secure属性的说明，标记为Secure的Cookie只应通过被HTTPS协议加密过的请求发送给服务端，它永远不会使用不安全的HTTP发送（本地主机除外）。MDN还明确写到：不安全的站点（URL中带http:）无法使用Secure属性设置Cookie。

“从安全来源发送”指的是设置这条Cookie的响应本身来自安全上下文。核对时可以看这次请求的地址是不是https开头。

一个自建示例（练习数据）：假设你在练习目录里用HTTPS地址打开自建页面，服务器返回下面这行：

Set-Cookie: __Secure-token=abc123; Secure

这行同时满足__Secure-的两条要求：有Secure，且从安全来源发送。如果去掉Secure，或者把地址换成http开头，浏览器会在Set-Cookie阶段拒绝它。

本节只讲Secure和来源安全这两条共同门槛。__Host-多出的Domain和Path条件放在下一节。

__Host-在共同门槛之外，还要求Cookie不包含Domain属性，并且Path属性设置为/。这两条是它比__Secure-更严的地方。

按MDN的说明，__Host-前缀的Cookie“不包括Domain属性，并将Path属性设置为/”。也就是说，只要Set-Cookie里出现了Domain=，或者Path写成了/docs这类非根路径，带__Host-的名称就不会被接受。

一个自建对照（练习数据，不是对某个真实网站的记录）：

Set-Cookie: __Host-id=xyz789; Secure; Path=/

这行满足__Host-的全部四项：有Secure、从安全来源发送、没有Domain、Path为/。

Set-Cookie: __Host-id=xyz789; Secure; Domain=example.test; Path=/

这行多了Domain，不满足“不包括Domain属性”这一条，会被拒绝。

Set-Cookie: __Host-id=xyz789; Secure; Path=/docs

这行的Path不是/，不满足“Path属性设置为/”这一条，也会被拒绝。

核对时把这两条单独列出来，不要和Secure、来源安全混在一起看。

按MDN的说明，带有这些前缀的Cookie，如果不符合其限制的会被浏览器拒绝。拒绝发生在浏览器处理Set-Cookie响应头的时候，也就是这条Cookie不会被保存下来。

这一点决定了排查方向：如果一条带前缀的Cookie“没生效”，先看响应头里的Set-Cookie行本身，而不是先怀疑后续请求为什么没带上它。因为如果它在Set-Cookie阶段就被拒绝，后面根本不存在这条Cookie，也就谈不上发送。

MDN还提到一个相关细节：在应用程序服务器上，Web应用必须检查完整的Cookie名称；用户代理程序在将其发送到请求的Cookie标头之前，不会从Cookie中剥离前缀。也就是说，前缀是名称的一部分，服务器端读到的名称仍然带着__Host-或__Secure-。

一个自建情境（示例）：你在练习目录里维护自建页面，服务器返回一条带__Host-前缀但Path写错的Set-Cookie。刷新后在开发者工具的存储查看器里找不到这条Cookie，说明它在Set-Cookie阶段就被拒绝了。这一步只用来观察，不修改任何系统设置。

把两个前缀的条件并排列出来，核对时不容易漏项。下表是编辑根据MDN说明整理的对照（示例，不是官方表格）：

| 条件 | __Host- | __Secure- |

| --- | --- | --- |

| 用Secure标记 | 要求 | 要求 |

| 从安全来源发送 | 要求 | 要求 |

| 不包含Domain属性 | 要求 | 不要求 |

| Path设置为/ | 要求 | 不要求 |

核对动作可以按这个顺序走：

1. 看名称带哪个前缀。

2. 检查Set-Cookie行里有没有Secure。

3. 确认这次响应来自安全来源。

4. 如果是__Host-，再检查有没有Domain、Path是不是/。

四步都过，这条Cookie才会被接受。任何一步不过，浏览器就拒绝。

前缀的作用是让浏览器在Set-Cookie阶段断言关于这条Cookie的特定事实。按MDN的说明，__Host-前缀的Cookie可以被视为“domain-locked”，__Secure-前缀的限制要弱于__Host-前缀。

需要说清边界。前缀核对解决的是“这条Cookie符不符合前缀条件、会不会被浏览器接受”，它不解决Cookie值本身是否安全，也不涉及会话固定攻击的具体过程。MDN在讲Secure属性时也提醒：Secure不会阻止对Cookie中敏感信息的访问。

另外，MDN指出，关于Cookie前缀和浏览器支持的当前状态，可以参阅Set-Cookie参考文章的前缀部分。不同浏览器版本的支持情况可能不同，核对时以你实际使用的浏览器行为为准。

本文只讲这两个前缀各自的条件和拒绝行为，不讲SameSite，也不讲会话固定攻击细节。