CSRF 防护要核查哪几层
CSRF 的成立条件是浏览器自动携带凭据：攻击者诱导已登录用户访问恶意页面，借会话发起用户不知情的状态变更请求。防护因此分三层：会话令牌校验（同步令牌与请求绑定）、Cookie 的 SameSite 属性、以及高风险操作的二次确认。核查的重点不是「有没有做」，而是覆盖面——改造过的主站表单通常有保护，被遗漏的往往是 API、旧版接口与内部调用路径。
基本信息
| 令牌层 | Token 绑定会话且服务端强制校验，包含全部状态变更请求 |
|---|---|
| Cookie 层 | 会话 Cookie 设置 SameSite=Lax 或 Strict，避免默认 None |
| 业务层 | 改密、转账、删除等高风险操作要求重新认证或验证码 |
| 核查方式 | 对照接口清单逐条确认，重点看旧版与批量接口 |
| 判定依据 | OWASP 相关防护建议与 CSRF 令牌规范 |
典型使用场景
- 新系统上线的安全评审，确认防护方案是否覆盖全部写接口
- 改造后复核：新版接口做了防护，旧版接口是否同步
- 判断某个接口是否真的可被跨站触发（结合 Cookie 属性一起看）
- 客服与运营后台的防护评审：这类系统常有批量操作接口
- 修复验证：确认令牌不可预测、与会话绑定且每次校验
核查清单
核查清单
□ 所有 POST/PUT/DELETE 接口是否校验 Token（含批量与旧版接口）
□ Token 是否与会话绑定、是否可预测、是否在会话内轮换
□ Cookie 的 SameSite 属性是否明确设置（Lax/Strict，而非默认）
□ 高风险操作是否有二次确认（重认证、验证码、口令确认）
□ 跨域与第三方集成场景是否引入放宽 CORS 的例外
□ 内部调用路径与开放接口是否有独立鉴权，不依赖浏览器凭据现象与判断
| 现象 | 含义 | 处置 |
|---|---|---|
| 写接口无任何令牌校验 | 依赖 Cookie 自动携带，可被跨站触发 | 列为缺陷，要求补充令牌校验 |
| 令牌与会话无关 | 跨站场景仍可复用 | 要求令牌与会话绑定并服务端校验 |
| SameSite=None 且无其他防护 | 跨站请求会携带凭据 | 评估必要性，必要时改为 Lax 或补令牌 |
| 高风险操作仅前端确认 | 前端校验可被绕过 | 要求服务端二次校验 |
接口改造后常遗漏历史版本与内部调用路径：逐条对照接口清单，而不是抽查几个主流程接口。
SameSite=None 与宽松 CORS 组合会同时扩大跨站攻击面：两者叠加时应当作组合风险单独评估，而不是各自判为低危。