初始配置Secure与SameSite=None的非会话认证Cookie丢失Secure属性问题咨询

该现象是低版本.NET框架的Cookie处理实现缺陷 + 现代浏览器Cookie合规兜底规则共同作用的结果，完整逻辑链与你观察到的时间特征完全匹配：

• 原生兼容能力缺失：MVC3基于早期版本的.NET Framework构建，HttpCookie类设计阶段完全没有内置SameSite字段支持，要实现SameSite="None"的配置，只能通过手动给Cookie的Attributes集合追加自定义键值对实现，框架内部从设计上就不会留存这类非原生的自定义属性。
• 属性丢失的触发节点：你当前的认证Cookie是14天有效期的非会话Cookie，且FormsAuthentication默认开启滑动过期机制。当满足续期条件时，框架会自动重新生成同名认证Cookie并通过Set-Cookie响应头回写；但老版本框架的Cookie拷贝逻辑存在设计缺陷，回写时仅保留Cookie名称、值、路径、域名、过期时间等基础字段，既不会留存你手动追加的SameSite配置，也不会对手动构造的Cookie自动补全web.config中requireSSL=true要求的Secure属性——这就是你看到的“Secure属性无故丢失”的直接来源。
• 浏览器侧的自动修正逻辑：Chrome、Firefox的内置Cookie合规规则明确要求，标记为SameSite=None的Cookie必须配套Secure属性才会被正常保留。当检测到回写的认证Cookie丢失了Secure属性时，浏览器会自动将该Cookie的SameSite值降级为Lax，同时同步移除缺失的Secure标记，整个修正过程无需服务端二次下发指令，也就形成了“Cookie创建至少2天后才出现属性变更”的观察结果。

• 放弃依赖框架自动补全Cookie属性的逻辑：在全局Application_EndRequest生命周期钩子中，对所有出站的Set-Cookie响应做统一拦截，针对认证Cookie强制覆盖所有要求的属性值：
  • 显式设置Secure = true、HttpOnly = true
  • 通过Attributes["SameSite"] = "Lax"显式追加SameSite配置，无论框架之前生成的响应内容是什么，统一在响应输出前完成属性覆盖，避免框架逻辑漏写安全配置。
• 你计划将SameSite调整为"Lax"的方向完全适配当前场景：SameSite=Lax不强制要求配套Secure属性，既可以规避老版本框架对SameSite=None的兼容缺陷，也符合现代浏览器的默认Cookie规则，能够覆盖绝大多数业务场景下跨站跳转携带Cookie的需求。测试阶段仅需确认顶级导航GET请求的Cookie携带逻辑符合业务预期即可。
• 保留现有web.config的全局Cookie配置：<httpCookies httpOnlyCookies="true" requireSSL="true" />的配置无需修改，作为兜底校验逻辑，避免其他场景下生成的Cookie出现安全属性缺失。

内容的提问来源于stack exchange，提问作者WoodmanBlockerville