是的，在某些情况下您不希望 HTTP ONLY 或 SECURE。

如果您需要 javascript 来查看 cookie 值，则删除 HTTP-Only 标志。几个案例 - 一些网站使用 javascript 来跟踪 cookie 中的页面状态以读取和写入 cookie 值。CSRF 缓解通常依赖于服务器在 cookie 中发送一个值，并期望 javascript 读取该值。

安全标志更为重要。如果我们希望所有站点都通过 https 运行，并且只有 https，那么唯一的 http 部分就是重定向到 https。您永远不希望您的 cookie 以明文形式发送。嗯，几乎从来没有。以下是您可能的两种情况：

1. 开发环境通常没有，或者不需要有 TLS 证书（虽然也许他们应该）。
2. 跟踪源自 http 的活动。您甚至可以使用负载均衡器在它发回重定向之前设置一个不安全的 cookie。然后，您的应用程序分析可以跟踪哪些 URL 作为 HTTP 进入。您的负载均衡器可以跟踪哪些会话以 http 形式传入。

在实践中，如果您正在运行 https 站点，请始终设置安全 cookie，并且始终通过设置 HTTPONLY来确保安全，除非您知道您的 javascript 需要 cookie 访问权限。

更新 - 开发中的 TLS

很多关于你是否应该在开发中使用 TLS 的讨论。在这里发布问题：

我应该打开还是关闭 TLS 进行开发？

关于httponly您本质上是在询问它们是否是需要通过 Javascript 读取或设置 cookie 的用例。通常，用户界面的某些设置（语言选择...）会以这种方式保留，如果 cookie 是 httponly，则会中断。

至于secure：因为根据您的描述，该站点一直在使用 https，因此拥有所有 cookie 并没有什么坏处secure。

安全标志

考虑到应用程序是通过HTTPS运行的，即LB将所有80端口的流量重定向到443，仍然需要根据以下场景启用安全标志。

1. 假设存在开发故障，导致超链接包含 HTTP（例如http://example.com/some_page.php）链接而不是 HTTPS（例如https://example.com/some_page.php）。 php ) 链接。
2. 由于没有安全标志，浏览器通过 HTTP 请求 Web 资源并连同它一起发送 cookie。
3. 请求到达 LB，LB 将流量重定向到端口 443，即通过 HTTPS。
4. 浏览器重新发起请求，但这次是通过 HTTPS 使用 cookie 值。

因此，尽管 LB 被配置为将端口 80 的不安全流量重定向到端口 443 的安全流量，但成功的 MiTM 攻击可能发生在step 2通过窃取敏感 cookie 导致冒充用户的情况下。此外，与在敏感 cookie 上启用安全标志相比，验证超链接和重定向是否正确编码是一项相对更加费力的活动。总而言之，尽管在 LB 级别设置了重定向，但由于缺少安全标志，可能会执行富有成效的 MiTM。

httponly 标志

这是一个标志，其意义独立于传输层安全性 (SSL/TLS)。httponly 标志用于防止 javascript 在成功的跨站点脚本 (XSS) 攻击事件中访问敏感 cookie，例如会话 cookie。如果未在 cookie 值上设置 httponly 标志，由于应用程序级缺陷而注入应用程序的恶意 javascript 最终可能会通过读取会话 cookie 并将其发送到远程服务器来破坏用户帐户的机密性、完整性和可用性。 ，从而成功冒充合法用户。因此，应该始终在所有 cookie 或至少敏感的 cookie 上设置 httponly 标志。

我会给你一个非 httponly cookie 的实际例子。

当访问者来到我的网站时，他/她的喉咙里塞了两个饼干。

phpsession -> secure httponly samesite:lax
cookie_law -> secure samesite:lax

包含一个 base64 编码的cookie_lawjson 编码的 cookie 对象，用于存储 cookie 设置。

我的 javascript 读取这些 cookie 以确定加载分析，adwords 依赖于权限或状态。
我的 javascript 也使用该 cookie 来使 cookie 设置编辑器工作。

如果我在 cookie 上设置 httponly 标志，则 javascript 无法读取它。由于多层缓存，我无法在渲染脚本时使用 php 来确定加载状态。这就是为什么我选择离开那个 cookie 的 httponly。

javascript 需要访问才能读取它。