HttpOnly是服务器通过Set-Cookie响应头设置的安全标志，浏览器禁止JavaScript访问该Cookie以防御XSS窃取会话凭证；必须与Secure、SameSite配合使用才真正有效。
Set-Cookie 响应头里必须加 HttpOnly 标志
HttpOnly 不是 HTML 能控制的，它由服务器在设置 Cookie 时通过 Set-Cookie 响应头声明。浏览器收到带 HttpOnly 的 Cookie 后，会禁止 JavaScript 通过 document.cookie 读取或修改它——这是防 XSS 窃取会话凭证的核心机制。
常见错误是前端试图用 document.cookie = "name=value; HttpOnly" 设置，这完全无效：浏览器会静默忽略 HttpOnly 属性，且该写法本身语法错误。
- 后端设置示例（Node.js/Express）：
res.cookie('sessionid', 'abc123', { httpOnly: true, secure: true, sameSite: 'lax' }) - PHP 中：
setcookie('token', 'xyz', ['httponly' => true, 'secure' => true, 'samesite' => 'Lax']) - Java Servlet：
cookie.setHttpOnly(true)配合response.addCookie(cookie)
HttpOnly 必须搭配 Secure 和 SameSite 才真正有效
单独设 HttpOnly 只防 JS 访问，但不防网络层窃听或 CSRF。如果 Cookie 在 HTTP 明文传输，中间人仍可劫持；若未限制 SameSite，攻击者网站发起请求也能带上该 Cookie。
生产环境务必同时启用：
立即学习“前端免费学习笔记（深入）”；
-
Secure：确保 Cookie 仅通过 HTTPS 传输（开发环境 localhost 可例外） -
SameSite=Strict或SameSite=Lax：阻断跨站请求携带 Cookie，大幅降低 CSRF 风险 - 注意：
SameSite=None必须显式配Secure，否则现代浏览器拒绝设置
JavaScript 无法读取 HttpOnly Cookie，但需确认是否真生效
测试是否生效最直接的方式是打开浏览器开发者工具 → Application → Cookies，查看目标 Cookie 的 “HttpOnly” 列是否打钩。如果没勾，说明后端设置有误。
常见失效原因：
- 响应头写错格式，比如写成
Set-Cookie: name=value; httponly（小写、缺等号）→ 必须是HttpOnly（首字母大写，无等号） - 反向代理（如 Nginx）覆盖或清除了原始
Set-Cookie头，需检查 proxy_cookie_flags 配置 - 某些老旧框架默认禁用
HttpOnly，需显式开启（如 Django 的SESSION_COOKIE_HTTPONLY = True）
HttpOnly 不解决所有 XSS 问题，只是关键一环
它只保护 Cookie 不被 JS 读取，但无法阻止 XSS 攻击本身。攻击者仍可通过伪造请求、重放操作、键盘记录等方式危害用户。所以：
- 仍需严格过滤输入、转义输出、使用 CSP
- 敏感操作（如转账、改密）必须服务端二次验证（如短信/邮箱确认），不能只依赖 Cookie
- 短期有效的会话 Token 比长期有效的更安全，配合
Max-Age或Expires控制生命周期
很多人以为加上 HttpOnly 就万事大吉，其实它只是防御纵深里的一层——漏掉任何一层，都可能让整个防护失效。
