CORS 为什么会成为安全兵家必争之地
浏览器默认拒绝跨域请求，是 Web 安全基石。CORS 作为官方放权机制，让服务端通过响应头声明允许哪些外部站点读取资源。但这个设计隐含一个矛盾：如果响应头设置过于宽松，等于帮攻击者绕过同源策略；如果过于严格，又会阻止合法的第三方集成。许多团队直接复制 Access-Control-Allow-Origin: *，或写死单一域名，这两种做法都忽略了凭证传递、预检请求、非简单方法与响应头暴露等细节，导致安全事件频发。
精细化配置的本质，是把 CORS 从“一刀切”变成“每个资源、每个 HTTP 方法、每个请求头都能独立控制”的策略。以下从响应头字段语义出发，逐步拆解如何安全地放权。
CORS 核心响应头逐字段精细配置
Access-Control-Allow-Origin：真正的白名单
该字段值可以是 * 或具体来源（如 https://trusted.example.com）。* 不兼容 withCredentials，因此需要携带 Cookie、Token 或证书的请求必须使用具体来源。精细化做法是：服务端动态获取请求头 Origin，与本地的白名单列表比对；若匹配则赋值，否则不发送该响应头或返回错误状态码。注意：不要直接把用户输入的 Origin 反射回响应头，否则会引入反射型跨域漏洞。
Access-Control-Allow-Methods 和 Allow-Headers
对于非简单请求，浏览器先发出 OPTIONS 预检。如果服务器返回的方法/头列表不包含实际请求使用的值，浏览器会阻塞后续请求。精细化配置应该：只列出业务真实需要的方法（如 GET、POST、PUT），不要写 * 或全量 HTTP 方法。Headers 同理，仅放行 Content-Type、Authorization、X-Requested-With 等必要头，屏蔽不用的自定义头。
Access-Control-Max-Age：预检缓存的博弈
缓存预检响应可以减少 OPTIONS 请求次数，但过长的缓存时间会让策略变更后客户端仍使用旧预检结果。安全推荐值：设置为当前预检资源的有效窗口（如 600 秒），不要超过 86400 秒。如果预检策略高度动态，可以直接设为 0。同时服务器必须正确处理 OPTIONS 请求，返回一致的逻辑。
Access-Control-Expose-Headers
默认情况下，浏览器只暴露 Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma 六个简单响应头。如果需要前端 JS 读取自定义响应头（如 X-Total-Count 用于分页），必须显式声明 Access-Control-Expose-Headers: X-Total-Count。没有必要把所有响应头都暴露，防止敏感信息泄露。
Vary: Origin 的必要性
当 Access-Control-Allow-Origin 值动态变化时，如果使用了 CDN 或反向代理缓存，必须添加 Vary: Origin，让缓存根据请求 Origin 头部区分不同来源的响应副本。否则 User-A 的响应可能被错误地返回给 User-B，导致 Allow-Origin 与请求不匹配，甚至触发跨域读取攻击。
精细化配置的最佳实践
- 严格校验 Origin： 不信任请求头中的
Origin，只与维护的白名单列表比对。白名单使用精确匹配或二级域名验证，避免正则注入。 - 区分凭证与非凭证请求： 需要发送 Cookie 或 Authorization 头时，不能用
*，必须显式指定来源且服务端响应Access-Control-Allow-Credentials: true。同时该来源必须经过严格安全审查。 - 服务端 CORS 中间件分层： 不同路由组配置不同的 CORS 策略。例如公开 API（
/api/public/**）可以允许任意来源读取，但需确保不带凭证；敏感 API（/api/admin/**）只允许内网或特定域名。 - 避免 OPTIONS 频繁触发： 对于简单请求（GET、POST 且 Content-Type 为
application/x-www-form-urlencoded、multipart/form-data、text/plain），不会发送预检。精细化配置时应尽量设计 API 使用简单请求，减少预检带来的延迟和安全风险。 - 日志与监控： 记录被拒绝的跨域请求来源，及时发现恶意探测或配置错误导致的合法请求被误拦截。
CORS 配置不当引发的安全风险
风险一：任意跨域读取敏感数据
如果 Access-Control-Allow-Origin: * 且 Credentials: false，攻击者可以在自己站点嵌入 <script> 或 fetch 请求目标站点公开资源。虽然不携带 Cookie，但目标站点如果依赖 IP 或自定义标头来识别用户（如内网 API），攻击者依然可以发起请求并读取响应内容（只要目标站点不验证来源）。更危险的情况：使用反射式 Origin 且未校验，攻击者直接伪造 Origin: https://evil.com，服务器返回 Access-Control-Allow-Origin: https://evil.com，导致任意站点可读取。
风险二：凭证暴露与 CSRF-like 攻击
当 Access-Control-Allow-Credentials: true 且 Allow-Origin 设置为攻击者可控的域名时，攻击者可以在自己站点诱导用户访问，自动携带目标站点的 Cookie 发送请求。尽管浏览器会限制跨域响应体读取（需要 Access-Control-Allow-Origin 不包含 * 且与当前站点匹配），但攻击者可以通过预定义响应格式（如 JSONP）或利用 script 标签执行返回的脚本内容，造成实际的信息泄露。
风险三：预检缓存中毒
如果服务器错误的处理了 OPTIONS 请求（例如返回 Access-Control-Allow-Origin: * 且 Max-Age 很大），攻击者可以诱使客户端浏览器缓存一个过度宽松的预检响应。之后用户在访问同一 API 时，浏览器直接使用缓存中允许任意来源的预检结果，使得后续实际请求绕过服务端的正常策略。
风险四：子域名接管
很多站点允许父域名下的所有子域名跨域（如 *.example.com）。如果某个子域名被攻击者接管（如通过 CNAME 指向恶意外部服务），攻击者就可以利用该子域名发起合法跨域请求，访问父域名下受保护的 API。精细化配置应避免使用通配符子域名，而采用精确列表或二级域名正则匹配（确保不会匹配到不存在的子域名）。
实际配置示例：Nginx 与 Spring
Nginx 层级精细化
location /api/ {
if ($http_origin ~* ^https://(trusted1.example.com|trusted2.example.net)$) {
add_header Access-Control-Allow-Origin $http_origin always;
add_header Access-Control-Allow-Credentials true always;
add_header Vary Origin always;
}
if ($request_method = OPTIONS) {
add_header Access-Control-Allow-Methods "GET, POST, PUT";
add_header Access-Control-Allow-Headers "Content-Type, Authorization, X-Requested-With";
add_header Access-Control-Max-Age 600;
return 204;
}
}上述配置使用正则校验 Origin，只允许明确列出的两个域名携带凭证。预检缓存 600 秒，既减少延迟又避免过度缓存。
Spring Boot 基于注解
@CrossOrigin(origins = {"https://app.example.com", "https://partner.example.com"},
methods = {RequestMethod.GET, RequestMethod.POST},
allowedHeaders = {"Content-Type", "Authorization"},
exposedHeaders = {"X-Tracking-Id"},
allowCredentials = "true",
maxAge = 600)
@RestController
public class UserController { ... }或者使用全局配置 WebMvcConfigurer，对不同的 API 路径设置不同的 addCorsMappings 规则，实现更细粒度的控制。
结论：平衡功能与安全的 CORS 策略
CORS 不是“加个响应头就完事”的特性，它需要与认证、会话管理、CSRF 防护协同工作。精细化配置的核心是：知道每个字段的用途与副作用，对请求来源、方法、头进行精确的白名单控制，并始终考虑带凭证场景下的风险。在生产环境中，建议使用安全审计工具扫描 CORS 配置，检查是否存在通配符与凭证共存、允许任意来源、预检缓存过长等问题。只有将 CORS 视为安全第一的边界控制点，才能既解决跨域问题，又不引入新的攻击面。
延伸阅读