JavaScript本身不操作Session，防范CSRF的关键在于后端生成绑定Session的CSRF Token并下发，前端通过响应头或JSON获取后存于内存，敏感请求须携带该Token；服务端严格校验其与Session的一致性、时效性及一次性，并配合SameSite=Lax/Strict、HttpOnly、Secure的Cookie策略协同防护。
JavaScript 本身不操作 Session，防范 CSRF 的关键在于后端生成并管理安全令牌（如 CSRF Token），前端配合正确传递和使用，同时配合 Cookie 安全策略形成协同防线。
用 Session 绑定 CSRF Token 并下发到前端
服务端在用户建立 Session 后（如登录成功），生成一个加密、一次性或短期有效的 CSRF Token，并存入当前 Session 存储中（如 Redis）。随后通过响应头或 JSON 响应体将该 Token 返回给前端，例如：
- 响应体字段：
{"csrfToken": "a1b2c3..."} - 或自定义响应头：
X-CSRF-Token: a1b2c3...
前端 JavaScript 获取后，将其保存在内存变量或模块级常量中（避免存 localStorage，防 XSS 窃取），后续敏感请求（如 POST/PUT/DELETE）必须携带该 Token。
前端请求时正确携带 Token
所有需防护的请求，都应在请求头或请求体中附带 Token：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
推荐方式：添加请求头
Authorization: Bearer <csrf-token>或X-CSRF-Token: <token> -
表单场景：将 Token 作为隐藏字段写入 form，如
<input type="hidden" name="_csrf" value="a1b2c3..."> - AJAX/fetch 请求需手动注入，不能依赖自动 Cookie 携带 —— 因为 CSRF 防护靠的是“额外凭证”，而非认证凭据本身
服务端严格校验 Token 与 Session 关联性
每次收到含 Token 的请求，后端必须执行以下校验：
- 从请求中提取 Token
- 根据当前请求携带的 Session ID（来自 HttpOnly Cookie），查出对应 Session 中存储的原始 Token
- 进行恒定时间比对（防止时序攻击），且验证 Token 未过期、未重复使用（尤其对关键操作建议一次性）
- 校验失败则直接拒绝，返回 403
注意：不能仅校验 Token 是否存在，也不能把 Token 存在客户端可篡改的位置（如 URL 参数）后直接信任。
配合 SameSite + HttpOnly Cookie 构建基础防线
Session Cookie 是 CSRF 防护的底层信任锚点，其配置直接影响 Token 机制有效性：
- SameSite=Strict 或 Lax：浏览器默认不发送跨站 Cookie，大幅降低攻击面；Lax 兼顾用户体验（允许安全的 GET 导航）
- HttpOnly：阻止 JavaScript 读取 Session ID，防范 XSS 窃取会话标识
- Secure：确保 Cookie 只通过 HTTPS 传输，防止中间人截获
- 禁止前端用
document.cookie读写 Session Cookie —— 它应完全由浏览器自动管理
Token 和 Cookie 是分工协作关系：Cookie 证明“你是谁”，Token 证明“这次请求是你主动发起的”。缺一不可。
