ASP.NET Core REST API的Anti Forgery Token最佳实践疑问

针对你提出的5个疑问，逐一解答如下：

1. 跨域发起请求时，Anti Forgery Token Cookie被包含是否仍有风险？ #

没有风险。原因在于：

• 跨域AJAX请求默认不会自动携带Cookie，除非前端显式设置withCredentials: true，且后端CORS配置允许携带凭证；
• 即便Cookie被携带，ASP.NET Core的Anti Forgery机制要求Token必须同时存在于Cookie和请求头（或表单参数）中。而同源策略限制了攻击者的恶意页面无法读取你的Cookie内容，也就没法将Token值放到请求头里，后端校验时会因缺少匹配的Token拒绝请求，从而阻断风险。

2. 已有授权Cookie，为何还要用存于Cookie的Anti Forgery Token？ #

CSRF攻击的核心是浏览器会自动为跨域请求携带目标站点的Cookie，攻击者根本不需要获取Cookie的具体内容，只要诱导用户触发请求（比如点击恶意链接、加载恶意图片），浏览器就会自动带上授权Cookie。

而Anti Forgery Token的作用是：攻击者无法通过同源策略读取到Cookie中的Token值，也就没法构造包含正确Token的请求。后端只有在Cookie和请求头/表单中的Token匹配时才会处理请求，这样就彻底阻断了攻击者利用浏览器自动带Cookie的特性发起的CSRF攻击。

3. 是否应将Anti Forgery Token存在localStorage并通过请求头发送？ #

不推荐这么做。理由是：

• localStorage属于前端可访问存储，容易被XSS攻击窃取，一旦Token被盗，攻击者就能直接构造合法请求；
• Cookie存储Token时，可通过设置HttpOnly、SameSite=Lax/Strict、Secure等属性，避免被XSS读取，同时限制Cookie的发送场景，安全性远高于localStorage；
• ASP.NET Core的Anti Forgery机制默认就采用Cookie+请求头的模式，完全适配框架的校验逻辑，无需额外改造。

4. Anti Forgery Token的刷新频率应为多少？ #

没有固定标准，可根据业务场景调整：

• 常规场景：15-30分钟刷新一次，和用户会话周期同步即可，平衡安全性和性能；
• 敏感操作场景：比如转账、修改密码等，可在每次操作前刷新Token，进一步降低风险；
• 不建议每次请求都刷新，会增加后端生成Token的开销。另外，ASP.NET Core可通过配置Anti Forgery Cookie的过期时间来控制Token有效期，刷新时需生成新Token并更新Cookie，同时作废旧Token。

5. 启用CORS后，后端会拒绝跨域请求，攻击者如何实施CSRF？为何仍需Anti Forgery Token？ #

CORS并非万能的CSRF防护手段：

• CORS仅限制AJAX类的跨域请求，但HTML表单的跨域提交不受CORS限制，攻击者可构造恶意表单，诱导用户提交，浏览器会自动携带授权Cookie，此时CORS无法拦截；
• 若CORS配置不当（比如误将恶意域名加入允许列表、设置Access-Control-Allow-Origin: *且允许携带凭证），会直接失去跨域限制能力；
• 即便CORS配置正确，也无法防范同域下的XSS攻击衍生的CSRF风险，而Anti Forgery Token能同时覆盖这些场景。

因此，启用CORS后仍需搭配Anti Forgery Token，形成完整的防护体系。

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