根据 RFC 6265 的第 4.1.2.5 节，可以在不安全的通道（例如 HTTP）上设置安全 cookie 。它明确提到安全标志只提供机密性而不是完整性，因为安全标志的 cookie 仍然可以从不安全的通道设置，覆盖任何先前设置的值（通过安全通道或其他方式）：

Secure 属性将 cookie 的范围限制为“安全”通道（其中“安全”由用户代理定义）。当 cookie 具有 Secure 属性时，只有当请求通过安全通道（通常是 HTTP over Transport Layer Security (TLS) [RFC2818]）传输时，用户代理才会在 HTTP 请求中包含 cookie。

虽然看起来对于保护 cookie 免受网络攻击者的攻击很有用，但 Secure 属性只保护 cookie 的机密性。活跃的网络攻击者可以覆盖来自不安全通道的安全 cookie，从而破坏它们的完整性（有关详细信息，请参阅第 8.6 节）。

第 8.6 节给出了几个例子，但由于该节太长，我不会在这里复制粘贴它们。

至于为什么，我知道没有明确的用例。我怀疑 RFC 是从仅以保护机密性为目标的角度编写的，因此在通过 HTTP 设置时阻止安全标记的 cookie 被接受是该目标的不必要限制。我的猜测是，基本原理是“如果我们提供此功能，人们可能会认为 cookie 的完整性受到 Secure 标志的保护，我们不希望人们做出这种假设”。

也就是说，可以通过不安全的通道设置数据这一事实在某种程度上否定了仅通过安全通道发送 cookie 值的概念，因此该决定的敏感性是有争议的。RFC 至少确实提到，如果这样做，您将失去机密性和完整性。

TL;博士

至少在基于 Chromium 的浏览器和 Firefox 中，不再可能使用不安全的来源

• 设置带有Secure标志的 cookie，或
• Secure覆盖标志为真的cookie 。

更多细节

在提出问题时，draft-ietf-httpbis-cookie-alone-01已经被提议（2016 年 9 月 5 日）以防止非安全来源设置带有“安全”标志的 cookie。这些建议后来（2017 年 4 月 25 日）合并到draft-ietf-httpbis-rfc6265bis-01 中：

合并了来自 [draft-ietf-httpbis-cookie-alone] 的建议，删除了非安全源设置带有“安全”标志的 cookie 并覆盖“安全”标志为真的 cookie 的能力。

该功能被称为“Strict Secure Cookies”，已添加到 Chromium并成为 Chrome 58 中的默认行为，但需要注意以下几点：

这确实为 cookie 驱逐留下了一个例外，这仍然可能导致安全 cookie 的删除，但只有在所有非安全 cookie 都被驱逐之后。

严格的安全 Cookie（在 Firefox 的遥测中称为“COOKIE_LEAVE_SECURE_ALONE”）也成为 Firefox 52 中的默认行为。

引用多项式提到的rfc6265已淘汰的rfc2965 ：

安全的

选修的。Secure 属性（无值）指示用户代理在发送回此 cookie 时仅使用（未指定）安全方式联系源服务器，以保护 cookie 中信息的机密性和真实性。

用户代理（可能与用户交互）可以确定它认为适合“安全”cookie 的安全级别。Secure 属性应被视为从服务器到用户代理的安全建议，表明保护 cookie 内容符合会话的利益。 当它向服务器发送一个“安全”cookie 时，用户代理应该使用不低于从服务器接收到 cookie 时使用的相同级别的安全性。

（强调我的）

我的解释是，他们希望服务器在通往客户端的路上负责安全，并有办法告诉客户端它应该这样做。

事实上，正如多项式的回答中提到的那样，结果是可疑的。

目前在网络上，我们必须接受许多浏览器及其用户通常会尝试通过不安全 (HTTP) 连接访问网络资源。

因此，RFC中关于何时可以设置带有 Secure cookie 标志的 cookie 存在一些漏洞。具体来说，是的，即使您是通过 HTTP 连接进行设置，也允许使用 Secure 标志设置 cookie。

Secure 标志只能用于增强安全性，因此从技术或安全的角度来看，没有理由阻止它发挥作用，尽管这并不是说这样做是个好主意。从效率的角度来看，使用必要的身份验证信息（在带有 Secure 标志的 cookie 中）响应登录请求，然后将用户重定向到 HTTPS，新的身份验证 cookie 将实际发送到该处，这可能是合理的。

此时可能已经发送了 HSTS 标头，因此浏览器将来不会再次尝试使用 HTTP，从而减轻未来的 cookie 覆盖攻击。

现在您认为攻击者可能已经截获了初始 cookie 数据并因此使用它来冒充用户是正确的。这不太理想。但这取决于用户通过 HTTP 连接到站点并接收 HSTS 标头而没有攻击者篡改/剥离此标头。这就是我们预加载 HSTS 的原因。为此，cookie 安全标志预加载可能是一个有趣的概念！

可以假设，在设置 cookie 后，用户在网络攻击方面唯一的风险是浏览器没有针对相关域的 HSTS 指令。然后，攻击者强制用户取消身份验证（可能通过阻止 SSL 流量，并等待用户尝试重新输入最有可能启动 HTTP 连接的地址），拦截身份验证凭据和/或令牌，删除安全标记并确保客户端不会发生 HTTPS 重定向（同时可能会在必要时与服务器协商）。