Spring Framework WebFlux CORS配置：全局与细粒度控制方案-优快云博客

Spring Framework WebFlux CORS配置：全局与细粒度控制方案

【免费下载链接】spring-framework spring-projects/spring-framework: 一个基于 Java 的开源应用程序框架，用于构建企业级 Java 应用程序。适合用于构建各种企业级 Java 应用程序，可以实现高效的服务和管理。项目地址: https://gitcode.com/gh_mirrors/sp/spring-framework

引言：解决跨域资源共享（CORS）的痛点

你是否在开发基于Spring Framework WebFlux的响应式应用时，遇到过前端跨域请求被浏览器拦截的问题？是否在尝试配置CORS时，面对全局配置与局部配置的优先级感到困惑？本文将深入探讨Spring WebFlux中的CORS（Cross-Origin Resource Sharing，跨域资源共享）配置方案，帮助你轻松实现全局与细粒度的跨域控制，确保前后端通信顺畅无阻。

读完本文，你将能够：

理解CORS的基本原理及在WebFlux中的实现机制
掌握全局CORS配置的多种实现方式
学会使用细粒度CORS控制满足复杂业务需求
解决常见的CORS配置冲突与问题
了解CORS配置的最佳实践与安全考量

CORS基础：为什么需要跨域资源共享？

同源策略与CORS

现代浏览器实施的同源策略（Same-Origin Policy）限制了来自不同源的文档或脚本如何与当前文档交互，这是一种重要的安全机制。然而，在实际应用中，前端应用与后端API服务往往部署在不同的域名下，需要进行跨域通信，此时就需要CORS机制来安全地绕过同源策略限制。

CORS通过在服务器端设置特定的HTTP头，告知浏览器允许哪些跨域请求。主要涉及以下HTTP头：

响应头	作用
Access-Control-Allow-Origin	指定允许访问的源
Access-Control-Allow-Methods	指定允许的HTTP方法
Access-Control-Allow-Headers	指定允许的请求头
Access-Control-Expose-Headers	指定允许客户端访问的响应头
Access-Control-Allow-Credentials	指定是否允许发送凭据（如cookies）
Access-Control-Max-Age	指定预检请求（Preflight Request）的缓存时间

简单请求与预检请求

CORS将请求分为两类：

简单请求（Simple Request）：满足特定条件的请求，直接发送实际请求，不需要预先检查。
预检请求（Preflight Request）：不满足简单请求条件的请求，浏览器会先发送一个OPTIONS方法的预检请求，确认服务器允许后再发送实际请求。

以下是简单请求的条件：

请求方法为GET、HEAD或POST
除了浏览器自动设置的头，只包含以下安全头：Accept、Accept-Language、Content-Language、Content-Type（仅限于application/x-www-form-urlencoded、multipart/form-data、text/plain）
请求中不包含自定义头
请求不发送凭据

Spring WebFlux CORS实现机制

Spring WebFlux通过CorsWebFilter处理CORS请求，其核心是CorsConfiguration类，该类封装了CORS相关的配置信息。

public class CorsConfiguration {
    private List<String> allowedOrigins;
    private List<OriginPattern> allowedOriginPatterns;
    private List<String> allowedMethods;
    private List<String> allowedHeaders;
    private List<String> exposedHeaders;
    private Boolean allowCredentials;
    private Boolean allowPrivateNetwork;
    private Long maxAge;
    // ... 其他方法
}

CorsConfiguration提供了丰富的方法来配置CORS规则，如setAllowedOrigins、setAllowedMethods、setAllowCredentials等。

WebFlux的CORS处理流程如下：

mermaid

全局CORS配置：统一管理跨域规则

全局CORS配置适用于应用中大部分接口需要相同跨域规则的场景，可以通过多种方式实现。

1. 实现WebFluxConfigurer接口

通过创建配置类实现WebFluxConfigurer接口，并重写addCorsMappings方法：

@Configuration
@EnableWebFlux
public class WebFluxConfig implements WebFluxConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedOrigins("https://example.com", "https://admin.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("Content-Type", "Authorization")
                .exposedHeaders("X-Total-Count", "X-Pagination")
                .allowCredentials(true)
                .maxAge(3600);
                
        // 可以添加多个映射规则
        registry.addMapping("/public/**")
                .allowedOrigins("*")
                .allowedMethods("GET")
                .maxAge(86400);
    }
}

CorsRegistry提供了链式API来配置CORS规则：

addMapping(String pathPattern): 指定应用CORS规则的路径模式
allowedOrigins(String... origins): 指定允许的源
allowedMethods(String... methods): 指定允许的HTTP方法
allowedHeaders(String... headers): 指定允许的请求头
exposedHeaders(String... headers): 指定允许客户端访问的响应头
allowCredentials(boolean allowCredentials): 指定是否允许发送凭据
maxAge(long maxAge): 指定预检请求的缓存时间（秒）

2. 声明CorsWebFilter Bean

通过直接声明CorsWebFilter类型的Bean，可以更灵活地配置CORS：

@Configuration
public class CorsConfig {

    @Bean
    public CorsWebFilter corsWebFilter() {
        CorsConfiguration corsConfig = new CorsConfiguration();
        corsConfig.setAllowedOrigins(Arrays.asList("https://example.com", "https://admin.example.com"));
        corsConfig.setAllowedMethods(Arrays.asList("GET", "POST", "PUT", "DELETE", "OPTIONS"));
        corsConfig.setAllowedHeaders(Arrays.asList("Content-Type", "Authorization", "Accept"));
        corsConfig.setExposedHeaders(Arrays.asList("X-Total-Count"));
        corsConfig.setAllowCredentials(true);
        corsConfig.setMaxAge(3600L);

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/api/**", corsConfig);
        
        // 添加多个URL模式的配置
        CorsConfiguration publicConfig = new CorsConfiguration();
        publicConfig.setAllowedOrigins(Arrays.asList("*"));
        publicConfig.setAllowedMethods(Arrays.asList("GET"));
        publicConfig.setMaxAge(86400L);
        source.registerCorsConfiguration("/public/**", publicConfig);

        return new CorsWebFilter(source);
    }
}

这种方式的优势在于：

可以更精细地控制CORS配置的优先级
可以在配置中使用条件逻辑
可以通过属性文件外部化配置

3. 使用允许所有源的默认配置

对于开发环境，可以使用允许所有源的简化配置：

@Configuration
public class DevCorsConfig {

    @Bean
    public CorsWebFilter corsWebFilter() {
        CorsConfiguration corsConfig = new CorsConfiguration();
        corsConfig.applyPermitDefaultValues(); // 应用默认允许值
        
        // 修改默认值以允许所有源和方法
        corsConfig.setAllowedOrigins(Collections.singletonList("*"));
        corsConfig.setAllowedMethods(Arrays.asList("GET", "POST", "PUT", "DELETE", "PATCH", "OPTIONS"));
        corsConfig.setAllowCredentials(false);
        
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", corsConfig);
        
        return new CorsWebFilter(source);
    }
}

applyPermitDefaultValues()方法会应用以下默认值：

允许的源："*"
允许的方法：GET, HEAD, POST
允许的头："*"
预检请求缓存时间：1800秒（30分钟）

注意：生产环境中不建议使用允许所有源的配置，应明确指定允许的源以保证安全性。

细粒度CORS控制：针对特定接口的定制化配置

当不同接口需要不同的跨域规则时，可以使用细粒度CORS控制。

1. @CrossOrigin注解

@CrossOrigin注解可以应用在控制器类或方法上，为特定接口定制CORS规则。

应用在控制器类上

@RestController
@RequestMapping("/users")
@CrossOrigin(
    origins = {"https://example.com", "https://app.example.com"},
    methods = {RequestMethod.GET, RequestMethod.POST, RequestMethod.PUT, RequestMethod.DELETE},
    allowedHeaders = {"Content-Type", "Authorization"},
    exposedHeaders = {"X-Total-Count"},
    allowCredentials = "true",
    maxAge = 3600
)
public class UserController {
    
    @GetMapping
    public Flux<User> getAllUsers() {
        // ...
    }
    
    @GetMapping("/{id}")
    public Mono<User> getUserById(@PathVariable String id) {
        // ...
    }
    
    // ... 其他方法
}

应用在控制器方法上

@RestController
@RequestMapping("/products")
public class ProductController {
    
    @GetMapping
    @CrossOrigin(origins = "*", methods = RequestMethod.GET, maxAge = 86400)
    public Flux<Product> getAllProducts() {
        // ...
    }
    
    @PostMapping
    @CrossOrigin(
        origins = {"https://example.com", "https://admin.example.com"},
        methods = RequestMethod.POST,
        allowedHeaders = {"Content-Type", "Authorization"},
        allowCredentials = "true"
    )
    public Mono<Product> createProduct(@RequestBody Mono<Product> product) {
        // ...
    }
    
    @PutMapping("/{id}")
    @CrossOrigin(
        origins = "https://admin.example.com",
        methods = RequestMethod.PUT,
        allowedHeaders = {"Content-Type", "Authorization"},
        allowCredentials = "true"
    )
    public Mono<Product> updateProduct(@PathVariable String id, @RequestBody Mono<Product> product) {
        // ...
    }
}

@CrossOrigin注解的属性

属性	描述
value/origins	指定允许的源
originPatterns	指定允许的源模式（支持通配符）
allowedHeaders	指定允许的请求头
exposedHeaders	指定允许客户端访问的响应头
methods	指定允许的HTTP方法
allowCredentials	指定是否允许发送凭据
allowPrivateNetwork	指定是否允许私有网络访问
maxAge	指定预检请求的缓存时间（秒）

2. 组合使用全局配置和@CrossOrigin注解

全局CORS配置和@CrossOrigin注解可以同时使用，此时两者的规则会合并：

允许的源、方法、头会取并集
预检请求缓存时间、是否允许凭据等单值属性，@CrossOrigin注解的值会覆盖全局配置

// 全局配置
@Configuration
public class WebConfig implements WebFluxConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("https://example.com")
                .allowedMethods("GET", "POST")
                .allowedHeaders("Content-Type")
                .maxAge(3600);
    }
}

// 控制器
@RestController
@RequestMapping("/orders")
public class OrderController {
    
    // 继承全局配置
    @GetMapping
    public Flux<Order> getAllOrders() {
        // ...
    }
    
    // 合并全局配置和注解配置
    @DeleteMapping("/{id}")
    @CrossOrigin(
        origins = {"https://example.com", "https://admin.example.com"},
        methods = RequestMethod.DELETE,
        allowedHeaders = {"Content-Type", "Authorization"},
        allowCredentials = "true"
    )
    public Mono<Void> deleteOrder(@PathVariable String id) {
        // ...
    }
}

上述例子中，deleteOrder方法的最终CORS规则为：

允许的源：https://example.com, https://admin.example.com（合并全局和注解配置）
允许的方法：GET, POST, DELETE（合并全局和注解配置）
允许的头：Content-Type, Authorization（合并全局和注解配置）
允许凭据：true（注解配置覆盖全局配置）
预检请求缓存时间：3600秒（使用全局配置）

3. 编程式CORS配置

对于更复杂的场景，可以在处理请求时动态配置CORS：

@RestController
@RequestMapping("/dynamic-cors")
public class DynamicCorsController {

    private final CorsConfiguration globalConfig;
    
    public DynamicCorsController() {
        // 初始化全局配置
        globalConfig = new CorsConfiguration();
        globalConfig.setAllowedOrigins(Collections.singletonList("https://example.com"));
        globalConfig.setAllowedMethods(Arrays.asList("GET", "POST"));
        globalConfig.setAllowedHeaders(Collections.singletonList("Content-Type"));
        globalConfig.setMaxAge(3600L);
    }
    
    @GetMapping("/{tenantId}/data")
    public Mono<ResponseEntity<Data>> getData(
            @PathVariable String tenantId,
            ServerWebExchange exchange) {
        
        // 根据tenantId获取特定租户的CORS配置
        CorsConfiguration tenantConfig = getCorsConfigForTenant(tenantId);
        
        // 合并全局配置和租户配置
        CorsConfiguration mergedConfig = globalConfig.combine(tenantConfig);
        
        // 应用CORS配置
        applyCorsConfiguration(exchange, mergedConfig);
        
        // 处理业务逻辑
        return dataService.getData(tenantId)
                .map(data -> ResponseEntity.ok(data));
    }
    
    private CorsConfiguration getCorsConfigForTenant(String tenantId) {
        // 从数据库或配置服务获取租户特定的CORS配置
        // ...
    }
    
    private void applyCorsConfiguration(ServerWebExchange exchange, CorsConfiguration config) {
        // 应用CORS配置到响应头
        if (config != null) {
            CorsUtils.setCorsHeaders(config, exchange.getResponse());
        }
    }
}

CORS配置冲突与解决方案

在实际应用中，CORS配置可能会出现冲突，导致跨域请求失败。

1. 允许凭据与允许所有源的冲突

问题：当allowCredentials设为true时，allowedOrigins不能设为"*"，否则浏览器会拒绝响应。

解决方案：使用allowedOriginPatterns代替allowedOrigins，或明确指定允许的源：

// 错误示例
registry.addMapping("/api/**")
        .allowedOrigins("*")  // 与allowCredentials=true冲突
        .allowCredentials(true);

// 正确示例1：使用allowedOriginPatterns
registry.addMapping("/api/**")
        .allowedOriginPatterns("https://*.example.com")
        .allowCredentials(true);

// 正确示例2：明确指定允许的源
registry.addMapping("/api/**")
        .allowedOrigins("https://example.com", "https://app.example.com")
        .allowCredentials(true);

2. 配置优先级问题

问题：多个CORS配置可能匹配同一个请求路径，导致预期之外的结果。

解决方案：了解CORS配置的优先级规则：

路径模式更具体的配置优先
显式声明的CorsWebFilter优先于通过WebFluxConfigurer配置的CORS规则

@Configuration
public class CorsConfig {
    
    @Bean
    public CorsWebFilter corsWebFilter() {
        // 配置1：更具体的路径模式，优先级更高
        CorsConfiguration apiConfig = new CorsConfiguration();
        apiConfig.setAllowedOrigins(Arrays.asList("https://api.example.com"));
        apiConfig.setAllowedMethods(Arrays.asList("GET", "POST", "PUT", "DELETE"));
        
        // 配置2：较通用的路径模式，优先级较低
        CorsConfiguration generalConfig = new CorsConfiguration();
        generalConfig.setAllowedOrigins(Arrays.asList("https://example.com"));
        generalConfig.setAllowedMethods(Arrays.asList("GET", "POST"));
        
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/api/v2/**", apiConfig);  // 更具体的路径
        source.registerCorsConfiguration("/**", generalConfig);      // 较通用的路径
        
        return new CorsWebFilter(source);
    }
}

3. 全局配置与@CrossOrigin注解的冲突

问题：全局配置与@CrossOrigin注解的规则可能冲突，导致意外结果。

解决方案：了解合并规则：

允许的源、方法、头会合并（取并集）
允许凭据、预检请求缓存时间等单值属性，注解配置会覆盖全局配置

// 全局配置
@Configuration
public class WebConfig implements WebFluxConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("https://example.com")
                .allowedMethods("GET", "POST")
                .allowedHeaders("Content-Type")
                .allowCredentials(false)
                .maxAge(3600);
    }
}

// 控制器方法
@DeleteMapping("/{id}")
@CrossOrigin(
    origins = "https://admin.example.com",
    methods = RequestMethod.DELETE,
    allowedHeaders = "Authorization",
    allowCredentials = true,
    maxAge = 1800
)
public Mono<Void> deleteItem(@PathVariable String id) {
    // ...
}

合并后的CORS规则：

允许的源：https://example.com, https://admin.example.com（合并）
允许的方法：GET, POST, DELETE（合并）
允许的头：Content-Type, Authorization（合并）
允许凭据：true（注解覆盖全局）
预检请求缓存时间：1800秒（注解覆盖全局）

高级主题：CORS配置的最佳实践与安全考量

1. 使用allowedOriginPatterns代替allowedOrigins

Spring 5.3引入了allowedOriginPatterns属性，支持更灵活的源匹配，同时解决了allowedOrigins与allowCredentials不能同时使用的限制。

// 使用allowedOriginPatterns配置子域名
registry.addMapping("/api/**")
        .allowedOriginPatterns("https://*.example.com", "https://*.example.cn")
        .allowedMethods("GET", "POST", "PUT", "DELETE")
        .allowedHeaders("Content-Type", "Authorization")
        .allowCredentials(true)
        .maxAge(3600);

// 使用allowedOriginPatterns配置端口范围
registry.addMapping("/dev-api/**")
        .allowedOriginPatterns("http://localhost:[3000-3010]")
        .allowedMethods("*")
        .allowCredentials(true);

allowedOriginPatterns支持以下模式：

*：匹配任意字符序列（不包含路径分隔符"/"）
**：匹配任意字符序列（包含路径分隔符"/"）
[0-9]：匹配数字范围
[a-z]：匹配字母范围
{sub1,sub2}：匹配多个选项之一

2. CORS与安全最佳实践

限制允许的源

生产环境中应明确指定允许的源，避免使用"*"：

// 推荐：明确指定允许的源
registry.addMapping("/api/**")
        .allowedOrigins("https://app.example.com", "https://admin.example.com")
        .allowedMethods("GET", "POST", "PUT", "DELETE")
        .allowedHeaders("Content-Type", "Authorization")
        .allowCredentials(true)
        .maxAge(3600);

// 不推荐：允许所有源
registry.addMapping("/api/**")
        .allowedOrigins("*")  // 生产环境中不安全
        .allowedMethods("*");

限制允许的方法和头

只允许必要的HTTP方法和请求头：

// 推荐：限制允许的方法和头
registry.addMapping("/api/**")
        .allowedOrigins("https://app.example.com")
        .allowedMethods("GET", "POST", "PUT")  // 只允许必要的方法
        .allowedHeaders("Content-Type", "Authorization")  // 只允许必要的头
        .allowCredentials(true)
        .maxAge(3600);

// 不推荐：允许所有方法和头
registry.addMapping("/api/**")
        .allowedOrigins("https://app.example.com")
        .allowedMethods("*")  // 允许所有方法
        .allowedHeaders("*"); // 允许所有头

谨慎使用allowCredentials

只有在确实需要跨域发送凭据（如cookies、HTTP认证信息）时，才启用allowCredentials：

// 仅在需要时启用allowCredentials
registry.addMapping("/api/auth/**")
        .allowedOrigins("https://app.example.com")
        .allowedMethods("POST")
        .allowedHeaders("Content-Type", "Authorization")
        .allowCredentials(true)  // 需要发送认证信息时才启用
        .maxAge(3600);

设置合理的maxAge值

预检请求缓存时间（maxAge）不宜设置过长或过短：

过长可能导致CORS规则更新后客户端无法及时获取最新规则
过短会增加预检请求的数量，影响性能

推荐设置为1小时（3600秒）到24小时（86400秒）：

// 推荐：设置合理的maxAge值
registry.addMapping("/api/**")
        .allowedOrigins("https://app.example.com")
        .allowedMethods("GET", "POST", "PUT", "DELETE")
        .allowedHeaders("Content-Type", "Authorization")
        .allowCredentials(true)
        .maxAge(3600);  // 1小时

3. 处理预检请求

预检请求（Preflight Request）是浏览器发送的OPTIONS方法请求，用于检查服务器是否允许实际请求。WebFlux会自动处理预检请求，但需要确保应用正确响应OPTIONS请求。

如果使用了自定义的WebFilter或Handler，需要确保OPTIONS请求能够到达CorsWebFilter：

@Configuration
public class FilterConfig {

    @Bean
    public WebFilter loggingFilter() {
        return (exchange, chain) -> {
            // 确保OPTIONS请求能够继续传播到CorsWebFilter
            if (CorsUtils.isPreFlightRequest(exchange.getRequest())) {
                return chain.filter(exchange);
            }
            
            // 处理其他请求...
            return chain.filter(exchange);
        };
    }
}

常见问题与解决方案

问题1：CORS配置不生效

可能原因：

CORS配置路径模式不正确
请求路径与配置的路径模式不匹配
配置类未被Spring扫描到
存在多个CORS配置，优先级导致预期配置未生效
应用了@CrossOrigin注解但类上没有@RestController或@Controller注解

解决方案：

检查路径模式是否正确：

// 正确：匹配/api开头的路径
registry.addMapping("/api/**")
        .allowedOrigins("https://example.com");

// 错误：缺少通配符，只匹配/api路径，不匹配/api/users等子路径
registry.addMapping("/api")
        .allowedOrigins("https://example.com");

确保配置类被Spring扫描到：

// 确保配置类位于Spring Boot应用类的包或子包下
@Configuration
public class WebConfig implements WebFluxConfigurer {
    // ...
}

检查是否存在多个CORS配置，确保预期配置的路径模式更具体：

// 更具体的路径模式优先
registry.addMapping("/api/v2/**")  // 更具体，优先级更高
        .allowedOrigins("https://app.example.com");

registry.addMapping("/**")  // 较通用，优先级较低
        .allowedOrigins("https://example.com");

问题2：Access-Control-Allow-Origin头未正确设置

可能原因：

配置的源与请求的源不匹配
使用了allowedOrigins("*")同时设置了allowCredentials(true)
请求被其他过滤器拦截，未到达CORS过滤器

解决方案：

检查请求的Origin头与配置的allowedOrigins是否匹配：

// 确保配置的源包含实际请求的源
registry.addMapping("/api/**")
        .allowedOrigins("https://example.com", "https://www.example.com");

当需要允许凭据时，不要使用"*"作为allowedOrigins，改用allowedOriginPatterns或明确指定源：

// 正确：使用allowedOriginPatterns
registry.addMapping("/api/**")
        .allowedOriginPatterns("https://*.example.com")
        .allowCredentials(true);

// 正确：明确指定源
registry.addMapping("/api/**")
        .allowedOrigins("https://example.com")
        .allowCredentials(true);

// 错误：同时使用"*"和allowCredentials(true)
registry.addMapping("/api/**")
        .allowedOrigins("*")  // 与allowCredentials冲突
        .allowCredentials(true);

问题3：预检请求失败

可能原因：

配置的allowedMethods不包含预检请求中的Access-Control-Request-Method
配置的allowedHeaders不包含预检请求中的Access-Control-Request-Headers
服务器未正确响应OPTIONS请求

解决方案：

确保allowedMethods包含所有需要的方法：

registry.addMapping("/api/**")
        .allowedOrigins("https://example.com")
        .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS");  // 包含OPTIONS方法

确保allowedHeaders包含预检请求中的所有请求头：

registry.addMapping("/api/**")
        .allowedOrigins("https://example.com")
        .allowedMethods("GET", "POST", "PUT", "DELETE")
        .allowedHeaders("Content-Type", "Authorization", "X-Custom-Header");  // 包含所有需要的头

总结与展望

CORS配置是Web应用开发中不可或缺的一部分，尤其是在前后端分离架构中。Spring WebFlux提供了灵活强大的CORS配置机制，包括全局配置和细粒度配置，可以满足各种复杂场景的需求。

本文详细介绍了WebFlux中CORS配置的多种方式：

全局配置：通过实现WebFluxConfigurer接口或声明CorsWebFilter Bean
细粒度配置：使用@CrossOrigin注解或编程式配置
解决常见问题的方案和最佳实践

随着Web应用的发展，CORS机制也在不断演进。Spring框架会持续跟进CORS规范的更新，提供更安全、更灵活的配置选项。作为开发者，我们需要：

深入理解CORS的工作原理
根据实际需求选择合适的配置方式
遵循安全最佳实践，保护应用免受跨域攻击
关注CORS规范和Spring框架的更新，及时调整配置策略

掌握WebFlux中的CORS配置，将帮助你构建更安全、更灵活的响应式Web应用，为用户提供更好的体验。

附录：CORS配置检查清单

为确保CORS配置正确，可使用以下检查清单：

基本配置检查

已明确指定允许的源（origins）
已明确指定允许的HTTP方法（methods）
已明确指定允许的请求头（allowedHeaders）
已根据需要配置暴露的响应头（exposedHeaders）
已正确设置是否允许凭据（allowCredentials）
已设置合理的预检请求缓存时间（maxAge）

安全配置检查

生产环境中未使用allowedOrigins("*")
未同时使用allowedOrigins("*")和allowCredentials(true)
只允许必要的HTTP方法和请求头
仅在必要时启用allowCredentials
已使用allowedOriginPatterns代替复杂的源配置

冲突检查

全局配置与@CrossOrigin注解的规则没有冲突
多个CORS配置的路径模式没有重叠或冲突
已处理CORS配置与其他过滤器的顺序问题

通过遵循本文介绍的方法和最佳实践，你可以轻松应对WebFlux应用中的跨域资源共享挑战，构建安全、高效的前后端通信桥梁。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考