本文旨在解决Checkmarx扫描报告中关于Spring应用中“过度宽松的CORS访问控制源头”的问题。我们将深入探讨CORS策略的原理，分析使用通配符带来的安全风险，并提供一种通过配置明确的域名白名单来加固应用安全性的解决方案，避免潜在的跨站攻击。
理解跨域资源共享 (CORS)
跨域资源共享 (CORS) 是一种浏览器安全机制，用于限制从一个源（域、协议和端口的组合）发起的 HTTP 请求访问与该源不同的资源。 这种限制旨在防止恶意网站访问用户的敏感数据。
默认情况下，浏览器实施同源策略，即只允许同源的脚本访问彼此的资源。CORS 通过在 HTTP 响应头中添加特定的信息来放宽此限制，允许服务器声明哪些源可以访问其资源。
问题根源：过度宽松的CORS配置
Checkmarx 报告的“过度宽松的 CORS 访问控制源头”问题通常源于使用通配符 * 作为 @CrossOrigin 注解的 origins 属性值。例如：
@CrossOrigin(origins = "*", allowedHeaders = "*", methods = {RequestMethod.GET, RequestMethod.OPTIONS, RequestMethod.POST, RequestMethod.PUT, RequestMethod.DELETE})这种配置允许任何域访问您的 API，这会带来严重的安全风险。恶意网站可以利用此漏洞发起跨站请求伪造 (CSRF) 攻击或窃取用户的敏感信息。
解决方案：配置域名白名单
为了解决这个问题，您应该避免使用通配符 *，而是配置一个明确的域名白名单，只允许受信任的域访问您的 API。
1. 修改 @CrossOrigin 注解:
将 origins 属性的值替换为一个包含允许访问您的 API 的域名的数组。例如：
@CrossOrigin(origins = {"https://yourdomain.com", "https://anotherdomain.com"}, allowedHeaders = "Accept,Accept-Language,Content-Language,Content-Type", methods = {RequestMethod.GET, RequestMethod.OPTIONS, RequestMethod.POST, RequestMethod.PUT, RequestMethod.DELETE})在这个例子中，只有 https://yourdomain.com 和 https://anotherdomain.com 能够跨域访问该方法。
2. Spring Boot全局CORS配置：
除了在方法级别使用 @CrossOrigin 注解，您还可以使用 Spring Boot 的全局 CORS 配置。 在WebMvcConfigurer中配置CorsRegistry，可以更灵活地管理CORS策略。
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
@Configuration
public class CorsConfig implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**") // 匹配所有请求路径
.allowedOrigins("https://yourdomain.com", "https://anotherdomain.com") // 允许的域名
.allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") // 允许的方法
.allowedHeaders("Accept", "Accept-Language", "Content-Language", "Content-Type") // 允许的header
.allowCredentials(true) // 是否允许发送Cookie
.maxAge(3600); // 预检请求的有效期，单位秒
}
}这种方式允许您集中管理CORS配置，避免在每个控制器方法上重复配置。addMapping("/**") 表示对所有请求路径生效。 您可以根据需要调整匹配的路径。
3. 考虑使用反向代理:
如果您的前端和后端部署在不同的域上，但都由您控制，可以考虑使用反向代理将它们部署在同一个域下。 这样可以完全避免 CORS 问题，因为所有请求都将来自同一个源。
注意事项
- allowedHeaders 属性: 建议明确指定允许的请求头，而不是使用通配符 *。
- allowCredentials 属性: 如果您的 API 需要发送 Cookie 或授权头，请确保将 allowCredentials 属性设置为 true。
- 预检请求: 浏览器在发起跨域请求之前，会先发送一个预检请求 (OPTIONS 请求) 到服务器，以检查服务器是否允许该跨域请求。 确保您的服务器能够正确处理预检请求。
- 安全测试: 在部署更改之前，务必进行充分的安全测试，以确保您的 CORS 配置符合安全要求。
总结
通过配置明确的域名白名单，您可以有效地解决 Checkmarx 报告的“过度宽松的 CORS 访问控制源头”问题，并提高您的应用程序的安全性。 记住，CORS 是一种重要的安全机制，应该谨慎配置，以防止潜在的跨站攻击。 始终遵循最小权限原则，只允许必要的域访问您的 API。
