React前端生成CSRF Token及CSRF防护方案咨询

1. 仅允许localhost:3000的CORS策略能否抵御CSRF？ #

能起到一定的防护作用，但不是完整的CSRF解决方案。
CORS是浏览器限制跨域请求的机制，它只拦截不符合规则的主动跨域请求，但CSRF攻击的核心是利用用户已登录的Cookie，通过第三方站点发起浏览器允许的请求（比如表单提交、GET请求）——这类请求不会触发CORS预检，甚至不会携带Origin头，你的CORS配置对这种情况完全无效。攻击者可以构造一个表单，直接提交到你的Node服务，浏览器会自动带上用户的登录Cookie，CORS策略拦不住这种请求。

2. 前端生成自定义Header Token的方案是否有效？ #

这个方案有效果但漏洞极大，根本起不到真正的CSRF防护作用。
密钥存在前端代码里，攻击者随便查看一下你的React源码就能拿到密钥，然后生成一模一样的Token放在请求头里发起攻击。后端的验证逻辑相当于形同虚设，因为攻击者完全可以复刻你的Token生成逻辑。

3. 给初学者的CSRF防护实用建议 #

• 用标准CSRF Token方案：后端生成随机的CSRF Token，存在用户Session里（或者存在允许前端读取的Cookie中），前端发起请求时把这个Token放到请求体或自定义Header里，后端验证Token和Session里的是否一致。核心是Token由后端生成，攻击者拿不到用户对应的有效Token。
• 给Cookie加SameSite属性：给登录态这类Cookie设置SameSite=Strict或SameSite=Lax。Strict会禁止第三方站点携带该Cookie，Lax允许部分安全的跨域请求携带，能大幅降低CSRF风险。
• 敏感操作别用GET请求：修改用户信息、提交订单这类操作必须用POST、PUT等方法，别用GET——GET请求很容易被攻击者通过链接、图片嵌入等方式触发。
• 辅助验证Origin/Referer头：后端可以检查请求的Origin或Referer头，确认来自信任的域名（比如localhost:3000），但注意有些场景下这些头会被浏览器隐藏，不能单独靠这个防护。

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