防范会话固定与Cookie劫持的核心在于前后端协同：登录成功后服务端必须销毁旧会话、生成新ID并重置Cookie，同时严格设置HttpOnly、Secure、SameSite三项安全属性，前端禁止手动操作或存储敏感令牌。

防范会话固定攻击和 Cookie 劫持，核心不在 JavaScript 本身做“拦截”或“加密”，而在于前后端协同配置——JS 只需不破坏安全机制，后端才是防线主体。关键动作是：登录成功时销毁旧会话、颁发新 Cookie，并严格设置安全属性。

登录时强制更新会话 ID（防会话固定）

会话固定攻击的前提是攻击者能诱导用户使用一个已知的会话 ID（比如通过 URL 参数 ?sid=abc123）。防御的关键是：用户真正完成身份认证后，服务端必须废弃原有会话，生成全新 session ID 并重置 Cookie。

• 前端无需生成或管理 session ID，也不应把登录前的 Cookie 当作有效凭证
• 登录接口返回成功后，浏览器会自动接收并替换新 Cookie（前提是后端正确 set-cookie）
• 若前端用 js-cookie 等库手动写入 sid，请立即删除——这会绕过 HttpOnly，反而引入风险

Cookie 必须启用三项基础安全属性

这些属性由后端在 Set-Cookie 响应头中设置，JS 不参与设置过程，但要确保不干扰其生效：

• HttpOnly：阻止 document.cookie 读取 session ID，XSS 脚本无法窃取
• Secure：仅在 HTTPS 下传输，防止中间人明文截获
• SameSite=Lax 或 Strict：限制跨站请求携带 Cookie，大幅降低 CSRF 和劫持利用面

注意：SameSite=None 必须搭配 Secure，否则现代浏览器拒绝设置；开发环境若无 HTTPS，可临时设为 SameSite=Lax + Secure=false，但上线前务必切回 Secure=true。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

立即学习“Java免费学习笔记（深入）”；

避免前端存储或操作敏感令牌

JavaScript 不该持有、解析或重写身份凭证类 Cookie：

• 禁止用 localStorage 存 JWT 或 session ID —— XSS 可直接读取
• 禁止用 document.cookie = 'sid=xxx' 手动设置 —— 绕过 HttpOnly，且易被篡改
• 如需前端读取非敏感状态（如语言偏好），可用 js-cookie 安全读取，但绝不用于权限判断

服务端配合：签名 + 短期有效期 + IP/UA 绑定（可选增强）

前端无法控制这些，但需理解它们如何与 Cookie 协同起作用：

• Cookie 值带 HMAC 签名（如 sid=abc123.hmac_xxx），服务端每次验证签名有效性
• 会话有效期不宜过长（如 30 分钟无操作即失效），降低被盗后利用窗口
• 高敏感场景可结合登录 IP 或 User-Agent 做轻量级绑定，异常变动时强制重新认证