JavaScript无法设置HttpOnly或Secure属性，必须由服务端通过Set-Cookie响应头下发；前端仅能读写非HttpOnly Cookie，安全凭证的生成、签名与校验必须由后端主导。
JavaScript 本身不能直接设置 HttpOnly 或 Secure 这类关键安全属性的 Cookie——这些必须由服务器端通过 Set-Cookie 响应头下发。前端 JS 只能读写非 HttpOnly 的 Cookie，因此安全认证凭证的生成、签名、下发和校验，必须交由后端主导，JS 仅承担辅助角色（如存储、携带、清理）。核心逻辑是：**服务端发令牌，客户端传令牌，服务端验令牌**。
服务端必须设置的关键安全属性
无论使用 Express、Next.js 还是 Spring Boot，下发认证 Cookie 时至少要包含以下三项：
- HttpOnly: true —— 阻止 JavaScript 读取，大幅降低 XSS 泄露风险
- Secure: true —— 强制仅在 HTTPS 下传输，防止中间人窃取
-
SameSite: 'Strict' 或 'Lax' —— 防御 CSRF 攻击；生产环境推荐
Lax（兼顾安全性与用户体验）
例如 Express 中：
res.cookie('auth_token', token, {httpOnly: true,
secure: true,
sameSite: 'lax',
maxAge: 7 * 24 * 60 * 60 * 1000 // 7天
});
前端 JS 的合理职责边界
JS 不该存密码或原始密钥，但可安全参与流程：
立即学习“Java免费学习笔记（深入）”；
- 登录成功后，不手动写
document.cookie，而是等待服务端响应自动设 Cookie - 登出时调用 API 触发服务端清除 Cookie，并用
Cookies.remove('auth_token')（js-cookie）同步清理可能残留的非 HttpOnly 副本 - 发起受保护请求时，无需手动加 Header——浏览器会自动携带匹配的 Cookie 到
fetch或XMLHttpRequest - 检查登录状态可用
Cookies.get('auth_token')快速判断（注意：这只是前端乐观判断，真实权限仍以服务端验证为准）
避免常见陷阱
很多安全问题源于混淆责任边界：
- ❌ 把 JWT 直接塞进普通 Cookie 且未设
HttpOnly→ XSS 可直接盗 token - ❌ 前端用
document.cookie = "token=xxx"手动设置 → 无法设HttpOnly，等同裸奔 - ❌ 后端 Cookie 缺少
Domain导致跨子域失效，或设错Path导致部分接口收不到 - ✅ 正确做法：服务端签发带签名的 short-lived token，存入
HttpOnly + Secure + SameSiteCookie；前端只负责触发登录/登出动作，不碰凭证内容
跨域场景下的特别处理
若前端域名（如 app.example.com）与 API 域名（如 api.example.com）不同，需额外配置：
- 服务端
Set-Cookie中明确指定Domain=.example.com（注意开头的点） - 前端
fetch请求必须开启credentials: 'include' - 服务端 CORS 响应头需含
Access-Control-Allow-Credentials: true且Origin不能为通配符*
