最新CSRF防御终极指南：2026后端开发实战

最新 CSRF 防御终极指南：2026 后端开发实战

一，CSRF 攻击原理

CSRF 跨站请求伪造，攻击者诱导用户在已登录状态，访问恶意页面，利用浏览器自动携带 Cookie，向目标网站发起状态修改请求。核心特点，攻击者拿不到 Cookie 内容，不需要窃取用户凭证，只借用当前用户登录身份执行操作。限制范围，仅改变数据的请求存在风险，GET 查询类接口一般无危害。同源策略不会拦截这类请求，只是阻止前端读取响应。很多误区，跨域和 CSRF 不是一回事，跨域是前端读取限制，CSRF 是利用浏览器自动提交带 Cookie 请求。

二，安全基础准则，必须遵守

1，不要用 GET 方法执行修改数据操作，新增，修改，删除，转账，绑定手机号，全部使用 POST PUT DELETE。GET 仅用于查询。 2，Cookie 基础三属性，HttpOnly，Secure，SameSite。HttpOnly 防止 JS 读取 Cookie，抵御 XSS 窃取会话。HTTPS 站点开启 Secure，仅 HTTPS 下发送 Cookie。 3，SameSite 三种取值。SameSite=Lax，默认推荐，外部链接跳转 GET 可携带 Cookie，跨站 POST 不发送。SameSite=Strict，完全禁止跨站发送 Cookie，适合金融，资金等高敏感业务。SameSite=None，仅第三方嵌入场景使用，必须搭配 Secure。 4，Cookie 推荐添加__Host - 前缀，限制只能在设置 Cookie 的域名使用，不能被子域名覆盖。

三，主流防御方案，生产选型

方案一，同步令牌模式，行业标准首选，有会话状态的后端。登录生成加密随机 Token，绑定当前用户会话，存储在服务端 session。表单放隐藏字段，AJAX 请求放在请求头 X-CSRF-Token。每次状态修改请求后端校验 Token，不匹配直接返回 403。优势，安全强度最高，主流框架 Spring Security Django Laravel 内置，开启中间件即可。要点，Token 必须不可预测，每个会话独立生成，不能固定不变。校验使用恒定时间比对，避免计时侧信道攻击。

方案二，双提交 Cookie 模式，适合无状态 SPA，边缘服务，不存储 session。后端下发签名 Token 到 Cookie，前端读取 Cookie，放到自定义请求头。后端同时读取 Cookie 和请求头的 Token，比对两者一致。Token 需要 HMAC 签名，绑定用户标识，防止篡改。注意，此方案依赖前端 JS 读取 Cookie，不能开启 HttpOnly。适合前后端分离无 session 场景，优先级低于同步令牌。

方案三，Origin 和 Sec-Fetch-Site 校验，纵深防御，不单独作为唯一防护。读取请求 Origin，Sec-Fetch-Site 请求头，状态修改请求校验来源域名。拒绝跨站发起的变更请求。 2026 推荐搭配 Token 一起使用，作为第二层防护。Referer 头可靠性差，可做辅助校验，不能作为主防御，Referer 可被浏览器隐藏。

方案四，自定义请求头，仅 API 接口辅助防护。要求 AJAX 请求携带自定义请求头，跨站简单请求无法携带自定义头，会触发 OPTIONS 预检。仅能作为辅助手段，不能单独用来防御 CSRF。

四，框架快速落地实战

SpringBoot Spring Security，默认开启 CSRF 防护，会自动生成 token。注意关闭不需要防护的接口，比如第三方回调，不要全局关闭 CSRF。 Django，CsrfViewMiddleware 默认启用，模板添加 {% csrf_token %}，前端 JS 从 Cookie 读取 csrftoken 放到请求头。 Gin Node Express，手动实现 Token 生成与校验，中间件拦截非 GET 请求做验证。重要提醒，第三方回调接口，支付通知，Webhook，不能加 CSRF 校验，这类请求来自外部，没有用户 Cookie。

五，分层防御最佳实践，2026 推荐方案

基础层，会话 Cookie 配置 SameSite=Lax，HttpOnly，Secure，__Host 前缀。核心层，所有状态变更接口启用 CSRF Token 校验。增强层，增加 Origin Sec-Fetch-Site 请求头校验。高敏感操作，转账，改密码，解绑设备，增加二次验证，短信验证码，人脸确认。

六，常见漏洞场景

场景 1，只做前端校验，后端没有校验 Token。前端校验可以绕过，后端必须强制校验。场景 2，Token 只做存在判断，没有绑定用户 session，Token 全局复用，攻击者拿到任意用户 Token 就能伪造请求。场景 3，全局关闭 CSRF 防护，很多开发图省事直接关闭框架 CSRF 中间件，造成全站漏洞。场景 4，第三方回调接口错误开启 CSRF 校验，业务回调请求直接 403。场景 5，SameSite=None 但没开启 Secure，HTTP 环境 Cookie 无法正常携带，同时引入安全风险。场景 6，子域名风险，子域名可控性差，SameSite 判定会把子域名当做同站，子域名被入侵会发起 CSRF 攻击。

七，排查步骤，漏洞定位

第一步，识别接口类型，区分查询接口和状态变更接口，只有修改数据接口需要防护。第二步，抓包查看 Cookie 属性，检查 HttpOnly Secure SameSite 配置。第三步，测试跨站页面发起 POST 请求，观察请求是否自动带上 Cookie，后端是否校验 Token。第四步，删除 Token，或者传入错误 Token，确认接口返回 403 拒绝访问。第五步，Origin 篡改测试，使用不同域名发起请求，校验 Origin 拦截逻辑。

八，高频踩坑清单

❌ SameSite=Lax 等于完全安全，SameSite 只是减少攻击面，不能替代 CSRF Token。 ❌ 只校验 Referer，Referer 会被浏览器省略，不能作为主防御手段。 ❌ 固定 Token，Token 不能写死，必须会话级动态生成。 ❌ 关闭 HttpOnly 方便前端读取 Token，双提交 Cookie 模式才需要关闭 HttpOnly，普通 session 场景禁止关闭。 ❌ 把 CSRF 和 CORS 混淆，CORS 是浏览器跨域读取限制，CSRF 是请求伪造，两套独立安全机制。 ❌ API 项目不需要 CSRF，只要接口依赖 Cookie 会话登录，就必须防护。使用 Token 鉴权 JWT 无 Cookie 场景，天然不受 CSRF 影响。

九，2026 新特性与趋势

Sec-Fetch 系列头部普及，现代浏览器自带 Fetch Metadata，后端可通过 Sec-Fetch-Site，Sec-Fetch-Mode 快速识别跨站请求，作为低成本纵深防护。 WAF 网关层面支持 CSRF 基础检测，可识别跨站状态变更请求，作为额外拦截层。 JWT 无 Token 鉴权，不依赖 Cookie，不会存在 CSRF 风险，但需要防范 XSS 窃取 JWT。安全审计要求，等保和数据安全评估中，CSRF 属于必查漏洞，高危业务建议多层防御。

十，上线前安全检查清单

1，所有 POST PUT DELETE 接口，开启 CSRF 校验，GET 查询接口无需校验。 2，会话 Cookie 配置 HttpOnly Secure SameSite，HTTPS 站点强制 Secure。 3，Token 绑定用户会话，使用加密随机生成，恒定时间比对。 4，Webhook，支付回调，第三方通知接口排除 CSRF 校验。 5，高敏感业务增加二次验证。 6，跨站模拟测试，验证错误 Token，跨站 Origin 请求返回 403。 7，禁止全局关闭框架自带 CSRF 防护。