JavaScript 无法设置 HttpOnly，因其由服务端通过 Set-Cookie 响应头声明；前端仅能在 HTTPS 页面中设置 Secure（针对非 HttpOnly Cookie），而真正安全需后端同时配置 Secure、HttpOnly 和 SameSite=Lax。
JavaScript 本身不能设置 HttpOnly 属性，这是关键前提。它只能参与设置 Secure（且仅在 HTTPS 页面中生效），而 HttpOnly 必须由服务端通过 Set-Cookie 响应头声明。两者配合才能真正防范 XSS 后的 Cookie 窃取和中间人劫持。
为什么 JS 无法设置 HttpOnly
HttpOnly 是浏览器强制执行的安全隔离机制：一旦服务端在响应头中带上 HttpOnly 标志，该 Cookie 就完全从 JavaScript 运行环境中隐藏——document.cookie 查不到、fetch 拿不到、任何前端脚本都无法读取或修改它。
- 这不是限制 API，而是浏览器底层策略，JS 没有对应接口
- 前端能做的，是接受“不可见”这个事实，并把敏感凭证（如 session_id、token）交由后端设为
HttpOnly - 如果某个 Cookie 在
document.cookie中可见，那它一定不是HttpOnly的
JS 中设置 Secure 的正确方式与限制
在已启用 HTTPS 的页面里，可以用 document.cookie 添加 Secure 标志，但必须严格满足条件：
- 当前页面协议必须是
https://，HTTP 页面中设置会静默失败 - 写法要规范：分号后不加空格，例如
document.cookie = "uid=123; Secure; Path=/; Max-Age=3600" - 仅适用于非
HttpOnly的 Cookie（因为 JS 本来就不能操作HttpOnly的） - 若还需防 CSRF，建议一并加上
SameSite=Lax：SameSite=Lax; Secure
真正安全的组合配置必须由后端完成
防范 XSS 窃取和中间人劫持，不能只靠前端。服务端下发 Cookie 时需同时声明三项：
立即学习“Java免费学习笔记（深入）”；
- Secure：确保只走 HTTPS 通道，防明文截获
- HttpOnly：切断 JS 访问路径，防 XSS 成功后的自动外传
- SameSite=Lax（或 Strict）：限制跨站请求携带，降低 CSRF 利用面
示例（PHP 7.3+）：setcookie('session_id', $value, [ 'httponly' => true, 'secure' => true, 'samesite' => 'Lax']);
如何验证是否生效
打开浏览器开发者工具 → Application → Cookies，查看目标域名下的条目：
- 带锁图标或明确标注 Secure 字样，说明传输受保护
- 对应 Cookie 不出现在
document.cookie输出中，且 JS 无法读取，说明 HttpOnly 生效 - 字段栏显示 SameSite: Lax 或 Strict，表示跨站策略已启用
