会话劫持风险，cookie配置HttpOnly
会话劫持是Web应用最常见的账号盗取手段之一，攻击者通过XSS脚本把用户Cookie传给自己的服务器，从而冒充登录。
要阻断这条链路，给Cookie加上HttpOnly属性是目前最直接有效的办法。
本文会带零基础读者从原理、配置、验证到排错，完整完成一次Cookie安全加固。
HttpOnly 为什么能挡住 JS 读取 Cookie
HttpOnly 是 Cookie 的一个扩展属性，它告诉浏览器：这个 Cookie 只能通过 HTTP(S) 请求自动携带，页面里的 document.cookie 和任何 JS 脚本都无法访问它。
也就是说，即使站内存在 XSS 漏洞，攻击者注入的脚本也取不到会话 Cookie。
只要 Cookie 带上了 HttpOnly，页面里的 JS 就完全看不到它，这能直接切断最常见的会话劫持路径。
但要注意，HttpOnly 只能限制 JS 读取，并不能阻止网络嗅探或攻击者通过其他方式窃取，所以它通常要和 Secure、SameSite 一起使用。
不同环境下给 Cookie 加上 HttpOnly
配置位置取决于你的技术栈，下面列出几种常用环境的设置方式。
PHP 环境
编辑 php.ini 文件，找到或新增以下配置：
session.cookie_httponly = On修改后重启 PHP-FPM 或 Apache 使其生效。
如果你不希望全局开启，也可以在代码里单独设置：
setcookie('session_id', $sessionId, [
'httponly' => true,
'secure' => true, // 建议同时开启，仅HTTPS发送
'samesite' => 'Lax'
]);Nginx 反向代理场景
Nginx 本身不直接生成 Cookie，但可以用 add_header Set-Cookie 强制覆盖；
这种方式容易破坏原有 Cookie，更推荐用 use_sticky 或修改上游应用。
如果上游是 PHP-FPM，你只需让 PHP 输出正确的响应头即可。
如果你需要验证上游返回的 Set-Cookie 是否正常，用 curl 查看：
curl -I http://你的域名Java / Spring 环境
在 Spring Boot 中，可以通过配置类统一设置：
ResponseCookie cookie = ResponseCookie.from("session_id", "value")
.httpOnly(true)
.secure(true)
.sameSite("Lax")
.build();也可以直接设置容器层的 SESSION_COOKIE_HTTP_ONLY=true（Tomcat、Jetty 都支持）。
如何确认 HttpOnly 已经生效
配置完成后，
打开浏览器开发者工具，
切换到 Application（Chrome）或 Storage（Firefox），
展开 Cookies 查看对应域名下的 Cookie。如果列表中显示 HttpOnly 列有对勾，
说明设置成功。
更直接的验证方式是：在网页控制台执行 document.cookie，如果你能看到目标 Cookie 的值，说明 HttpOnly 没生效；
如果输出空字符串或不包含该 Cookie，说明加固已经生效。
配置后容易踩的四个坑
- HttpOnly 只能由服务端设置，通过 JS 的
document.cookie创建的 Cookie 无法加这个属性，所以不要尝试用前端代码去开启。 - 确认代码里没有重复覆盖 Cookie。有些框架在响应头里写了两处 Set-Cookie，后写的会覆盖先写的，导致 HttpOnly 丢失。
- 浏览器缓存可能导致旧响应头残留，验证前建议用无痕窗口或 Ctrl+Shift+R 强制刷新。
- HttpOnly 不一定要和 Secure 绑定使用，但强烈建议同时开启。如果站点只有 HTTP 访问，Secure 会让 Cookie 无法发送，测试时请注意区分。
结尾：别只依赖 HttpOnly
会话劫持风险是多种因素叠加的结果，HttpOnly 只是第一道防线。
完成上述配置后，建议配合内容安全策略（CSP）过滤 XSS 脚本，并为会话设置合理的过期时间。
如果你按本文步骤操作后 Cookie 仍然能被 JS 读到，优先检查应用层有没有重复写 Cookie，再确认 PHP-FPM 或 Web 服务器的配置确实被正确加载。
如果你还想了解更多关于 Cookie 的 Secure 和 SameSite 设置，下一篇可以继续讨论它们在不同登录场景下的配合方案。
