javascript无法设置httponly属性，必须由服务端在set-cookie响应头中声明；前端用document.cookie添加“httponly”字样无效，浏览器仅将其视为普通值。
JavaScript 无法设置 HttpOnly，必须由服务端写入 Set-Cookie 响应头
“用 document.cookie 加 HttpOnly 字样”是无效操作——浏览器完全忽略这种写法，只会把 HttpOnly 当作 Cookie 值的一部分存下来。真正生效的 HttpOnly 只能由后端在 HTTP 响应头中声明。
常见错误现象：
- 前端代码写
document.cookie = "sessionid=abc; HttpOnly"，结果开发者工具里看不到 HttpOnly 标志 ✅ - 调用
document.cookie仍能读到该 Cookie ❌（说明没生效）
正确做法是服务端在首次下发会话 Cookie 时，直接在 Set-Cookie 头里带上 HttpOnly：
- Node.js / Express：
res.cookie('sessionid', 'abc123', { httpOnly: true }) - PHP：
setcookie('sessionid', 'abc123', ['httponly' => true]) - Java Servlet：
response.addHeader("Set-Cookie", "sessionid=abc123; Path=/; HttpOnly")
验证 HttpOnly 是否真正生效的三个动作
别只看代码写了没，要确认浏览器是否真的按规则执行了。
- 打开 Chrome 或 Edge 的开发者工具 → Application → Cookies → 找到对应 Cookie → 看
HttpOnly列是否打 ✅ - 在 Console 中执行
document.cookie，确认输出里不包含该 Cookie 名（比如没有sessionid=...） - 发起一个同域请求（如
fetch('/api/user')），用抓包工具（如 Network 面板）确认请求头中仍自动携带Cookie: sessionid=abc123
如果前两点都满足，但第三点没看到 Cookie 发出，大概率是路径（Path）、域名（Domain）或 Secure 属性配置不匹配导致浏览器拒绝发送。
HttpOnly 单独启用不够，必须搭配 Secure 和 SameSite
HttpOnly 只解决“JS 读不到”，不解决“被中间人截获”或“被跨站请求滥用”。上线前必须检查这三项是否协同生效：
-
Secure：确保 Cookie 仅通过 HTTPS 传输。HTTP 环境下可临时关闭，但生产环境必须开启；否则攻击者可在未加密连接中嗅探到sessionid -
SameSite=Lax：默认阻止跨站 POST 请求携带 Cookie，大幅缓解 CSRF。设为Strict更严，但可能影响用户体验（如从外部链接跳转时登录态丢失） - 路径与域名限制：
Path=/admin或Domain=app.example.com能缩小 Cookie 暴露面，避免被子域或无关路径下的脚本意外继承
错误示例：Set-Cookie: sessionid=abc; HttpOnly —— 缺少 Secure 和 SameSite，等于裸奔。
HttpOnly 不是银弹，它防不住 XSS 本身，也拦不住业务逻辑漏洞
设置了 HttpOnly 后，攻击者确实拿不到 sessionid，但不代表网站就安全了：
- XSS 依然存在：恶意脚本能篡改 DOM、伪造表单、监听键盘输入、重定向用户，只是不能直接窃取会话 ID
- 敏感操作仍需二次防护：转账、密码修改等接口不能只校验 Cookie，必须引入一次性 Token 或短信/邮箱确认
- 别把凭证存在
localStorage或sessionStorage：这些地方 JS 可随意读写，一旦 XSS 就全暴露 - 服务端仍要过滤和转义输出：比如用户昵称含
<script></script>，渲染前必须做 HTML 实体编码，否则HttpOnly也救不了
最常被忽略的一点：开发阶段用 http://localhost 测试时，Secure 会被浏览器静默丢弃，但很多人忘了上线前补上，结果生产环境 Cookie 在 HTTP 下明文传输。
