HttpOnly Cookie 由后端通过 Set-Cookie 响应头设置，禁用 JavaScript 访问以防御 XSS；前端仅需配置 credentials: 'include' 自动携带，不读取、不存储、不手动注入 Token。
HttpOnly Cookie 本身不能直接“存储 Token”，而是由后端在设置 Cookie 时启用 HttpOnly 标志，让浏览器禁止 JavaScript 访问该 Cookie —— 这正是它提升安全性的核心机制。前端 JavaScript 不应（也无法）主动创建或读取 HttpOnly Cookie，所有 Token 的写入、验证、刷新都必须通过后端接口完成。
为什么不能用 JS 操作 HttpOnly Cookie
HttpOnly 是浏览器强制执行的安全属性：一旦响应头中设置了 Set-Cookie: token=xxx; HttpOnly; Secure; SameSite=Strict，JavaScript 的 document.cookie 就完全无法读取或修改这个 Cookie。这是防御 XSS 攻击的关键防线 —— 即使页面被注入恶意脚本，也无法窃取 Token。
后端如何正确设置 HttpOnly Token Cookie
后端在用户登录成功后，生成 Token（如 JWT），并通过 HTTP 响应头下发带安全属性的 Cookie：
- 必须包含 HttpOnly：阻止 JS 访问
- 搭配 Secure：仅在 HTTPS 下传输（生产环境必需）
- 设置 SameSite=Strict 或 Lax：防范 CSRF（推荐 Lax，兼顾可用性）
- 合理设置 Expires/Max-Age：避免长期有效 Token 增加风险
- 避免在 Cookie 中存敏感字段：Token 本身应签名+加密，且 payload 不含密码等明文信息
前端如何配合实现安全交互
前端不碰 Token 字符串，只通过标准 HTTP 请求自动携带 Cookie：
立即学习“Java免费学习笔记（深入）”；
- 所有需要认证的请求（如
fetch('/api/profile', { credentials: 'include' })）需显式设置credentials: 'include' - 登录表单提交用
POST到后端登录接口，由后端返回 HttpOnly Cookie，前端无需解析响应体中的 Token - 登出时调用后端登出接口（如
POST /auth/logout），由后端清除 Cookie（Set-Cookie: token=; expires=Thu, 01 Jan 1970 00:00:00 GMT） - 无需在 localStorage/sessionStorage 中备份 Token，也不做手动 Authorization header 注入
补充建议：增强整体安全性
HttpOnly 是重要一环，但不是银弹：
- 后端需校验 Cookie 中 Token 的签名、过期时间、签发者等，并绑定用户设备指纹或 Session ID 做二次校验
- 敏感操作（如改密、支付）建议额外要求二次验证（短信/OTP）
- 前端仍需防范 XSS：及时升级依赖、避免 innerHTML 插入不可信内容、使用 CSP
- 考虑短期 Access Token + 长期 Refresh Token 分离机制，Refresh Token 同样走 HttpOnly Cookie
不复杂但容易忽略：安全不是某个技术点的事，而是 Cookie 属性、后端验证逻辑、前端调用方式、部署环境（HTTPS）、监控告警共同构成的闭环。
