Edge 139（Chromium内核）下ASP.NET SameSite=None Cookie拦截导致SAML认证故障的技术咨询

看起来你精准定位到了问题的核心——Chromium内核139版本对SameSite=None Cookie的Secure属性强制要求，这确实是你遇到SAML认证500错误的根因。我来逐个解答你的问题：

1. Edge 139（Chromium 139）是否强制拦截没有Secure标记的SameSite=None Cookie？ #

是的，完全正确。从Chromium 139版本开始，当Cookie被标记为SameSite=None时，浏览器会强制要求同时附加Secure属性，否则会直接拒绝存储该Cookie（也就是你在DevTools中看到的Set-Cookie警告对应的行为）。Edge作为基于Chromium的浏览器，严格遵循这一内核级规则——因为SameSite=None的设计本来就是为了跨站场景下的Cookie传递，这类场景下如果不通过HTTPS传输（即没有Secure标记），Cookie很容易被窃听或篡改，所以强制绑定Secure是逻辑上的必要安全加固。

2. 这个变化是Edge 139的安全更新/CVE修复的一部分吗？ #

这个规则的落地是Chromium安全路线图中既定的升级步骤，并非针对某个单一CVE的紧急修复，但确实是Edge 139版本的核心安全优化之一。Chromium项目团队早在几年前就预告了对SameSite=None Cookie的Secure属性强制要求，之前的版本可能存在过渡期（比如仅警告不拦截），而Chromium 139正式将警告升级为强制拦截，Edge同步跟进了这一内核更新，目的是彻底封堵跨站请求伪造（CSRF）和Cookie泄露的风险入口。

3. 正确的缓解措施是不是设置<httpCookies requireSSL="true" />，还有其他推荐方案吗？ #

对你的场景来说，设置<httpCookies requireSSL="true" />是最优且推荐的标准解决方案，原因如下：

• 你的应用完全运行在HTTPS环境下，启用requireSSL="true"会让ASP.NET自动为所有通过框架发出的Cookie（包括SAML认证流程中用到的会话Cookie、认证Cookie）添加Secure标记，完美适配Chromium 139的新规则。
• 这个配置是全局生效的，不需要在代码中逐个修改Cookie的设置，减少了遗漏的风险。

如果你的ASP.NET版本低于4.7.2，还需要额外注意：低版本的.NET Framework默认不会正确输出SameSite=None属性（会因为旧的浏览器兼容性逻辑跳过设置），这种情况下你需要安装对应的.NET Framework补丁（比如KB4533002），或者在代码中手动为SAML相关的Cookie设置SameSite=None和Secure属性。

另外，你也可以检查IIS的站点配置，确保没有自定义的Cookie设置覆盖了ASP.NET的配置；同时建议在其他主流浏览器（比如Chrome 139+、Firefox最新版）中做兼容性测试，确认修复效果一致。

内容来源于stack exchange