CORS配置能防御CSRF攻击吗？应该如何正确设置？

Code°景鑫提问于 2026-02-19 12:24:31 阅读 13

安全

我在用Spring Boot配置CORS时发现，设置了allowedOrigins为可信域名，但测试时用其他域名发起带token的POST请求居然成功了，这不还是存在CSRF漏洞吗？

后端配置是这样写的：

@Configuration
public class CorsConfig {
    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return r -> r.addCorsMappings("/**")
            .allowedOrigins("http://trusted-domain.com")
            .allowedMethods("GET", "POST")
            .allowCredentials(true);
    }
}

前端用fetch请求设置了：

fetch('/api/data', {
  method: 'POST',
  credentials: 'include'
})

但用另一个域名测试时，浏览器明明提示了跨域，却弹出了”允许跨域请求”的确认框，用户如果点了允许，请求就成功了。这说明CORS配置根本没挡住恶意站点发起的请求啊，那该怎么同时解决CORS和CSRF的问题？

我来解答赞 3 收藏

反馈

1 条解答

凌薇（打工版） Lv1

CORS 和 CSRF 是两个完全不同的安全机制，很多人容易把它们搞混。按照规范，CORS 的作用是控制哪些外部域名可以访问你的资源，而 CSRF 的防御则是防止跨站请求伪造。你遇到的问题其实是混淆了两者的职责。

先说为什么你的配置没能挡住 CSRF 攻击。CORS 的 allowedOrigins 只是用来告诉浏览器哪些域名可以发起跨域请求，但它不会阻止恶意站点发送带凭证的请求。如果用户的浏览器已经保存了有效的 cookie 或 token，恶意站点仍然可以通过用户的身份发起请求。浏览器弹出的“允许跨域请求”确认框只是 CORS 的预检机制的一部分，和安全性无关。

要解决 CSRF 问题，你需要在后端实现专门的防御机制。Spring Security 提供了内置的 CSRF 防护功能，你可以这样配置：

@Configuration

public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override

    protected void configure(HttpSecurity http) throws Exception {

        http.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())

            .and()

            .authorizeRequests()

            .anyRequest().authenticated();

    }

}

这个配置会在每次请求时检查一个 CSRF Token，前端需要把这个 Token 附加到请求中。比如在 fetch 请求里，你可以这样写：

function getCsrfToken() {

    const csrfCookie = document.cookie.split('; ')

        .find(row => row.startsWith('XSRF-TOKEN='));

    return csrfCookie ? decodeURIComponent(csrfCookie.split('=')[1]) : null;

}



fetch('/api/data', {

    method: 'POST',

    credentials: 'include',

    headers: {

        'X-XSRF-TOKEN': getCsrfToken()

    }

});

这里的关键点是：CSRF Token 必须由服务器生成，并且每个用户的 Token 都是唯一的。Spring Security 默认会把 Token 写入 Cookie 中（名字通常是 XSRF-TOKEN），前端从 Cookie 中读取后通过请求头 X-XSRF-TOKEN 发送回去。

至于 CORS 配置，你原来的代码其实没什么大问题，但建议把 allowedOrigins 的值限制得更严格一些，比如只允许特定的几个可信域名。如果你不需要支持所有 HTTP 方法，也可以进一步缩小 allowedMethods 的范围。

总结一下，CORS 和 CSRF 各司其职，不能互相替代。CORS 是为了控制跨域资源共享，CSRF 是为了防止跨站请求伪造。按照规范，应该同时启用两者来保证应用的安全性。

2026-02-19 13:07