PHP 8.6 会话安全默认值怎么影响旧项目：strict_mode、HttpOnly 与 SameSite

旧 PHP 项目准备跟进 8.6.0beta2 时，登录流程里最值得先查的不是框架版本，而是会话 ID 和 Cookie 的隐含约定。PHP 官方 RFC 已接受把三个会话安全默认值作为 PHP 8.6 目标变更，但这仍不等于稳定版已经切换。迁移前要把显式配置、跨站回调和自定义会话处理器逐项对上。

可以提前按 PHP 8.6 的目标默认值做兼容性回归：严格模式拒绝未初始化的会话 ID，HttpOnly 阻止 JavaScript 读取会话 Cookie，SameSite=Lax 收紧跨站携带；正式上线仍应以实际 PHP 版本和发布说明为准。

先把 RFC 里的三个默认值对上

这次变更的边界很窄，都是 session 扩展里的既有配置项，不会增加新的 ini 名称或 API。RFC 提议将 session.use_strict_mode 从 0 改为 1，将 session.cookie_httponly 从 0 改为 1，并把 session.cookie_samesite 从未设置改为 Lax。

判断环境时先记录实际的 PHP_VERSION 和 session_get_cookie_params()，再看 php.ini、容器环境变量或框架启动代码有没有显式覆盖。这样能分清“默认值变化”与“应用主动配置”这两种原因。

配图里的“版本目标”对应 PHP 8.6 与配置变更，“会话配置”对应三个配置项和显式配置，“兼容性边界”对应旧项目回归；这三个边界正好是迁移排查的范围。

session.use_strict_mode 先查谁在接管 SID

严格模式的核心不是让登录更“严格”，而是拒绝浏览器带来的未初始化会话 ID。PHP 手册说明，开启后如果收到的 ID 在会话存储中不存在，模块会放弃它并生成新的 ID，可缓解 session fixation。但旧系统若把固定 SID 当成子域之间的交接凭证，切换后就可能表现为“登录成功却没有共享登录态”。

先搜代码中的 session_id()、session_start() 和自定义 session_set_save_handler()。文件处理器场景下，发起方应先写入并关闭会话，再把 ID 交给接收方；自定义处理器则确认是否实现 validateId() 或等价校验回调。没有校验能力时，配置写成 1 也不能替代处理器设计。

HttpOnly 和 SameSite 检查前端契约

session.cookie_httponly=1 后，浏览器仍会在请求中携带会话 Cookie，但页面脚本不能通过 document.cookie 读取它。若旧前端把 PHP 会话 ID 当作自定义请求头或 CSRF 值，应该拆成单独的短期令牌，不要为了兼容而关闭 HttpOnly。

session.cookie_samesite=Lax 允许同站请求和安全方法的顶层跨站导航，但不会把会话 Cookie 带到跨站子资源或跨站 POST。依赖跨站 POST 的 SAML、旧式表单回调或嵌入式业务，需要针对对应入口明确使用 SameSite=None; Secure，并重新确认 HTTPS、CSRF 和回调校验。

配图里的“安全属性”是两个 ini 配置，“浏览器行为”是浏览器 Cookie、JavaScript document.cookie、同站请求和跨站 POST，“例外配置”是 SameSite=None; Secure。这里表达的是静态 Cookie 契约，不是请求执行流程。

升级前用一张清单做反向验证

这里别急着把三个值直接写进生产配置。先在与线上相同的 PHP 小版本、SAPI 和会话存储上做一次回归，记录失败请求的 Cookie、响应状态和入口类型。

1. 确认实际版本：区分稳定版、预发布版和 RFC 目标，保存 PHP_VERSION 与配置快照。
2. 确认会话来源：检查 URL、POST 或 Cookie 是否能注入外部 SID；若是自定义处理器，确认 ID 校验回调不是无条件返回成功。
3. 确认浏览器边界：验证前端不依赖 document.cookie 读取会话值，并单独测试同站登录、跨站 POST、SAML 回调。
4. 确认回退方案：把显式值放进可审计的配置文件，保留旧值只用于定位兼容问题，修复业务契约后再恢复安全默认。

最终验收看的是登录、登出、会话轮换、跨子域跳转和回调入口都能完成闭环，而不是只看响应头有没有出现一个属性。若改动后只剩跨站回调失败，优先缩小 SameSite 例外范围，不要全局关闭三个安全项。

常见问题

PHP 8.6 RFC 已接受，生产环境现在就会自动切换吗？

不能这样判断。RFC 的目标版本是 PHP 8.6，官方预发布页列出了 8.6.0beta2；实际服务器是否采用新默认值，要以已安装版本和对应发布说明为准。

开启 strict_mode 后，Redis 会话一定失效吗？

不一定。关键在会话处理器是否实现 ID 校验；先确认具体扩展和处理器的 validateId 行为，再测试已有会话、首次登录和会话轮换。

跨站 POST 必须把 SameSite 改回空值吗？

不必。只对确实需要跨站携带会话的入口评估 SameSite=None; Secure，同时保留 HTTPS、CSRF 和来源校验；其他会话继续使用 Lax 更容易收敛风险。