HttpOnly 是服务端在 Set-Cookie 中声明的标志，禁止 JavaScript 访问 Cookie，从而防止 XSS 成功后盗取 sessionid；需配合 Secure（仅 HTTPS 传输）和 SameSite（防 CSRF）才完整有效。
HttpOnly 本身不防 XSS，它防的是 XSS 成功后盗取 Cookie。只要正确启用，攻击者即使注入了恶意脚本，也无法通过 document.cookie、XMLHttpRequest 或 fetch 拿到带 HttpOnly 的会话标识（比如 sessionid）。
HttpOnly 是什么，为什么能缓解 XSS 风险
HttpOnly 是一个由服务端在 Set-Cookie 响应头中声明的标志，它的作用很明确：禁止浏览器中的 JavaScript 访问该 Cookie。
- ✅ 浏览器仍会在后续同域请求中自动携带这个 Cookie（不影响登录态）
- ❌ JavaScript 完全无法读取或修改它（
document.cookie里看不到，也设不了） - ⚠️ 它不阻止 XSS 发生，也不防 DOM 型 XSS 对页面其他部分的篡改
必须配合 Secure 才真正安全
只开 HttpOnly 不够。如果网站支持 HTTP 访问，而 Cookie 没加 Secure，攻击者可能通过中间人（MITM）在明文连接中截获它。
- 启用
Secure后，浏览器只在 HTTPS 请求中发送该 Cookie - 上线前务必确认全站已部署有效 TLS 证书，并强制跳转 HTTPS
- 开发环境若无 HTTPS，可临时关闭
Secure，但绝对不能上线
不同语言/框架的设置方式
关键原则：HttpOnly 和 Secure 必须作为 Cookie 属性写进 Set-Cookie 字符串，不能单独设响应头，也不能用 response.setHeader() 覆盖。
-
Node.js / Express：
res.cookie('sessionid', 'abc123', { httpOnly: true, secure: true, sameSite: 'Lax' }) -
PHP：
setcookie('sessionid', 'abc123', ['httponly' => true, 'secure' => true, 'samesite' => 'Lax']) -
ASP.NET Core： 在
ConfigureServices中配置options.Cookie.HttpOnly = true和options.Cookie.SecurePolicy = CookieSecurePolicy.Always -
Spring Boot（推荐）： 使用
ResponseCookie.from(...).httpOnly(true).secure(true).sameSite("Lax")构建再写入响应头
别忽略 SameSite 这个协同项
HttpOnly + Secure 主要防 Cookie 窃取，而 SameSite=Lax（或 Strict）能额外缓解 CSRF，属于低成本高收益的加固点。
-
Lax允许 GET 导航时携带 Cookie，兼容性好，适合大多数场景 -
Strict安全性更高，但可能导致跨站链接登录态丢失 - 若需跨站功能（如嵌入 iframe），必须设为
None，且强制搭配Secure
