跨域API架构下的CSRF防护方案咨询：Token获取与CORS配置疑问

你提到的这两种方案其实是互补而非互斥的，咱们先理清楚CSRF的核心逻辑，再拆解各自的作用、局限性，以及怎么组合才能实现可靠的防护——这也是为什么很多大型网站会结合使用类似第一种方案的原因。

先明确CSRF的核心本质 #

CSRF攻击的核心是：恶意网站利用浏览器自动携带用户Cookie的特性，在用户不知情的情况下发起跨域请求，让服务器误以为是用户主动操作。防护的关键就是让服务器能准确区分「用户主动发起的合法请求」和「恶意伪造的请求」。

两种方案的详细分析 #

1. 前端初始化调用/getCSRF获取Token的方案 #

你觉得这个方案不可靠，可能是担心Token泄露或者被滥用？其实只要做好细节，它是CSRF防护的核心手段之一：

• 为什么大厂会用？ 这个方案的核心是给每个用户会话绑定一个唯一的CSRF Token，服务器通过验证请求中的Token与会话绑定的Token是否一致，来判断请求是否合法。
• 关键可靠性保障：
  • Token要存在前端内存（比如Vue/React的state里），绝对不能存在localStorage/sessionStorage——避免XSS攻击导致Token被盗用；
  • 必须在请求头（比如X-CSRF-Token）里携带Token，不要放在URL参数里（URL参数容易被日志、referrer泄露）；
  • /getCSRF接口本身要加防护：只允许已登录用户调用，并且要校验请求的Origin头是否为frontend.domain.com，防止恶意网站批量获取Token。
• 单独使用的局限性：如果没有CORS限制，恶意网站可以先跨域调用/getCSRF拿到Token，再用这个Token发起伪造请求——所以它需要配合其他限制才能发挥最大作用。

2. 启用CORS仅允许frontend.domain.com的方案 #

这是跨域场景下的第一道防线，但它的局限性也很明显：

• 作用：浏览器的同源策略会阻止恶意网站通过AJAX直接向api.domain.com发起跨域请求，CORS配置则明确放行合法的前端域名请求，拦截大部分非法来源。
• 局限性：CORS管不了所有CSRF场景——比如恶意网站可以用HTML表单（<form action="https://api.domain.com/xxx" method="POST">）提交请求，这种请求不会触发CORS预检，浏览器会直接发送，服务器如果没做其他校验，还是会执行操作。

可靠的组合防护方案 #

正确的做法是同时启用两种方案，形成多层防护：

• 第一层：配置CORS规则，仅允许frontend.domain.com的请求访问API，拦截大部分非法跨域请求来源；
• 第二层：实现完善的CSRF Token机制：
  • 前端初始化时调用/getCSRF获取Token（存在内存中）；
  • 所有涉及数据修改的请求（POST/PUT/DELETE等）都在请求头中携带该Token；
  • 服务器端验证：检查请求头的Token是否与当前用户会话绑定的Token一致，不一致则直接返回403；
• 额外补充：如果有表单提交场景，要在表单中加入隐藏域携带CSRF Token，服务器同步验证表单中的Token。

补充：为什么有些大厂看似只用第一种方案？ #

其实很多时候是他们把CORS的校验逻辑集成到了/getCSRF接口里——比如接口会严格检查请求的Origin头是否为合法域名，只有frontend.domain.com的请求才能拿到Token，相当于把两种方案的防护逻辑结合在了一起，并不是真的只依赖Token方案。

内容的提问来源于stack exchange，提问作者shamon shamsudeen