JavaScript本身不直接管理Session，真正防护依赖后端生成验证的安全令牌（如JWT或session ID），配合HttpOnly+Secure+SameSite Cookie配置，前端禁止手动操作cookie或存储token至localStorage。
JavaScript 中的 Session 本身不直接处理安全令牌，真正起防护作用的是服务端生成并验证的 安全令牌（如 JWT 或随机 session ID），配合客户端（含 JS）正确使用和保护该令牌。会话劫持攻击（如窃取 cookie、XSS 获取 token）不能单靠前端 JS 防御，必须前后端协同设计。
使用 HttpOnly + Secure Cookie 存储 Session ID
这是防止 XSS 导致 Session ID 泄露的最基础防线。服务端在设置 session cookie 时应启用：
- HttpOnly：禁止 JavaScript 访问 cookie，避免 XSS 脚本读取 session ID
- Secure：仅通过 HTTPS 传输，防止中间人明文截获
- SameSite=Strict 或 Lax：防御 CSRF，间接降低会话被滥用风险
前端无需（也不应）用 document.cookie 读写该 cookie —— 浏览器自动在请求中携带，JS 无法干预。
若用 Token（如 JWT）代替传统 Session，务必安全存储
当采用无状态 Token 方案时，前端常需自行管理 token。关键原则是：
立即学习“Java免费学习笔记（深入）”；
- 避免存入 localStorage 或 sessionStorage —— XSS 可直接读取
- 推荐短期存于内存变量（如模块级 const token），结合登录后获取、请求前注入的方式
- 若必须持久化，可加密后存入 HttpOnly cookie（由后端签发并验证），前端 JS 不接触原始 token
例如：登录成功后，后端 set-cookie 返回一个加密过的 token cookie；后续 API 请求由浏览器自动附带，前端 JS 不解析、不操作它。
前端配合做最小必要防护
JS 虽不能替代服务端安全机制，但可辅助降低风险：
- 监听用户非活动时间，主动调用 logout 接口清除服务端 session
- 对敏感操作（如转账、改密）要求二次认证，不依赖当前 session 信任度
- 检查响应状态码（如 401/403）及时清空本地缓存凭证，避免无效 token 继续使用
- 避免在 URL、日志、错误提示中泄露 token 或 session 标识
服务端才是防御核心，前端只是配合环节
所有关键逻辑必须由服务端强制执行：
- Token 签名验证（如 JWT 的 HMAC/RS256）、有效期校验、黑名单机制（如登出时加入 Redis 黑名单）
- Session ID 绑定 IP/User-Agent（谨慎使用，注意隐私与兼容性）
- 定期刷新 token（滑动过期）、限制 token 使用范围（audience、scope）
- 对异常行为（如短时间多地区登录）触发风控，强制重认证
前端 JS 再严谨，也无法绕过服务端校验 —— 安全令牌的价值，始终取决于服务端是否严格验证它。
