跨域资源共享（CORS）策略收紧，本质上就是在网站开发框架层面，通过更严格的访问控制规则来限制哪些外部域名可以读取你的数据、调用你的接口、加载你的资源。过去很多开发者为了图省事，直接把Access-Control-Allow-Origin设置成通配符"*"，或者把凭证允许（Allow-Credentials）和通配符混用，这等于把大门敞开让任何人进来拿数据。现在行业趋势非常明确：框架默认策略越来越保守，安全审计越来越严格，你必须针对每个接口、每个资源路径做精细化的白名单配置，才能既保证业务正常运转，又堵住数据泄露的口子。

这篇文章会从CORS的核心机制讲起，拆解当前主流框架（Spring Boot、Express、Django、ASP.NET Core等）的默认收紧策略，给出具体的配置方案和代码示例，最后聊一聊实际项目中容易踩的坑和进阶防护手段。

一、CORS到底在防什么：从同源策略说起

浏览器有一个基础安全机制叫同源策略（Same-Origin Policy），要求协议、域名、端口三者完全一致才允许前端JavaScript直接读取响应数据。但现代Web应用天然需要跨域——前端在a.com，后端API在b.com，这时候就需要CORS来"开绿灯"。CORS的工作原理是：浏览器在发请求前先发一个预检请求（OPTIONS），服务器在响应头里声明"我允许哪些来源访问"，浏览器拿到这个声明后才决定是否把真实请求的响应数据交给JavaScript。

问题出在哪？出在服务器端的响应头配置太随意。如果你写了Access-Control-Allow-Origin: *，意味着任何网站都能通过浏览器读取你的API返回数据。如果这个API返回的是用户信息、订单详情、内部报表，那就是严重的数据泄露。更危险的是，如果你同时设置了Access-Control-Allow-Credentials: true，浏览器会允许携带Cookie和认证信息跨域请求，攻击者可以利用用户已登录的身份直接操作后端接口。

二、主流框架的默认收紧趋势

最近两年，几乎所有主流Web开发框架都在收紧CORS默认策略。具体表现有三个方面：

第一，默认不再允许通配符。Spring Boot 3.x、Express 5.x、Django 5.0、ASP.NET Core 8.0等框架，在没有显式配置CORS的情况下，默认不会添加任何Access-Control-Allow-Origin头。也就是说，你不配就等于拒绝所有跨域，必须主动声明白名单。

第二，凭证模式和通配符互斥被强制执行。过去有些开发者图方便写成Allow-Origin: *同时Allow-Credentials: true，浏览器虽然会报错，但有些老版本或代理层会放行。现在框架层面直接在代码逻辑里做了校验，两者同时出现会抛异常或者被拦截。

第三，预检请求缓存时间缩短。以前浏览器可以缓存OPTIONS响应长达24小时，现在很多框架把maxAge设得更短，甚至要求每次都重新验证，增加了攻击成本但也增加了正常请求的开销，需要在性能和安全之间做权衡。

三、Spring Boot中的精细化CORS配置

Spring Boot是Java生态里用得最多的后端框架，它的CORS配置方式有全局和局部两种。全局配置适合整个项目统一策略，局部配置适合针对特定Controller做差异化控制。

全局配置示例：

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/")
                .allowedOrigins("https://www.yourfrontend.com", "https://app.yourfrontend.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("Content-Type", "Authorization", "X-Request-ID")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

这段代码的关键点：allowedOrigins必须是具体的域名列表，不能用"*"；allowCredentials设为true时，allowedOrigins绝对不能是通配符；maxAge设为3600秒（1小时），在安全和性能之间取了一个平衡点。

如果你需要对某个Controller单独收紧，可以用注解：

@RestController
@RequestMapping("/api/sensitive")
@CrossOrigin(origins = "https://admin.yourfrontend.com", 
             methods = RequestMethod.GET,
             allowCredentials = "true")
public class SensitiveDataController {

    @GetMapping("/user-info")
    public UserInfo getUserInfo(@RequestHeader("Authorization") String token) {
        // 验证token后返回数据
    }
}

注意这里只开放了GET方法，只允许admin子域名访问，并且要求携带认证头。这种粒度的控制才是防止数据泄露的正确姿势。

四、Node.js Express框架的CORS中间件实践

Express框架通常使用cors中间件包来处理。最新版本的cors包默认行为已经非常保守，不传任何参数就不会添加任何CORS头。

推荐的配置方式：

const cors = require('cors');

const corsOptions = {
    origin: function (origin, callback) {
        // 动态白名单验证
        const whitelist = [
            'https://www.yourfrontend.com',
            'https://app.yourfrontend.com',
            'https://mobile.yourfrontend.com'
        ];
        if (!origin || whitelist.indexOf(origin) !== -1) {
            callback(null, true);
        } else {
            callback(new Error('Not allowed by CORS'));
        }
    },
    credentials: true,
    methods: ['GET', 'POST', 'PUT', 'DELETE'],
    allowedHeaders: ['Content-Type', 'Authorization', 'X-Request-ID'],
    maxAge: 3600,
    preflightContinue: false
};

app.use(cors(corsOptions));

这里用了一个origin回调函数做动态验证，比直接写死数组更灵活，可以根据环境变量或者数据库里的配置动态调整白名单。preflightContinue设为false表示不自动处理OPTIONS请求的后续逻辑，交给你自己的路由处理。

五、Django和ASP.NET Core的策略要点

Django推荐使用django-cors-headers库，配置集中在settings.py：

CORS_ALLOWED_ORIGINS = [
    "https://www.yourfrontend.com",
    "https://app.yourfrontend.com",
]

CORS_ALLOW_CREDENTIALS = True

CORS_ALLOW_METHODS = [
    'GET',
    'POST',
    'PUT',
    'DELETE',
]

CORS_ALLOW_HEADERS = [
    'content-type',
    'authorization',
    'x-request-id',
]

Django 5.0之后，如果你不设置CORS_ALLOWED_ORIGINS，默认就是空列表，不会允许任何跨域。这比以前的版本安全得多。

ASP.NET Core在Program.cs里配置：

builder.Services.AddCors(options =>
{
    options.AddPolicy("StrictPolicy", policy =>
    {
        policy.WithOrigins("https://www.yourfrontend.com", "https://app.yourfrontend.com")
              .WithMethods("GET", "POST", "PUT", "DELETE")
              .WithHeaders("Content-Type", "Authorization")
              .AllowCredentials()
              .SetPreflightMaxAge(TimeSpan.FromHours(1));
    });
});

app.UseCors("StrictPolicy");

ASP.NET Core 8.0的新特性是支持命名策略，你可以定义多个策略应用到不同的端点组，比如公开接口用宽松策略，敏感接口用严格策略。

六、除了CORS头，还有哪些配套防护手段

光靠CORS响应头是不够的。CORS只是浏览器层面的防护，攻击者完全可以用curl、Postman或者服务端程序直接发请求绕过浏览器限制。所以你必须在应用层做多重防护。

第一，接口认证必须独立于CORS。不管请求来自哪个域名，每个API调用都要验证Token、签名或者API Key。JWT、OAuth2.0、HMAC签名这些手段都要用上。

第二，敏感数据接口加频率限制和IP黑名单。用Redis或者令牌桶算法做限流，防止批量爬取。配合WAF（Web应用防火墙）做异常流量拦截。

第三，响应数据做最小化返回。不要把整个用户对象都塞进响应里，只返回前端真正需要的字段。比如用户列表接口只返回id、昵称、头像，不返回手机号、身份证号、邮箱。

第四，Content-Security-Policy（CSP）头要配好。CSP可以限制页面只能从指定域名加载脚本和资源，即使CORS被绕过，攻击者注入的恶意脚本也无法从外部加载依赖。

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; connect-src 'self' https://api.yourbackend.com;
七、实际项目中最容易犯的五个错误

错误一：开发环境用通配符，上线忘了改。很多团队在本地开发时为了方便把CORS设成"*"，部署到生产环境直接把代码推上去了，这是最常见的数据泄露原因。

错误二：把内部API和公开API混在同一个CORS策略里。内部管理接口应该只允许内网或特定管理域名访问，不应该和面向用户的公开接口共用同一套白名单。

错误三：忽略了子域名的区别。www.yourfrontend.com和app.yourfrontend.com是两个不同的Origin，必须分别加入白名单，不能想当然地认为父域名通了子域名就通了。

错误四：只防了GET请求，忘了POST/PUT/DELETE。有些开发者以为只有读取数据才需要防，但写入、修改、删除操作的数据泄露危害更大。

错误五：没有做CORS配置的自动化测试和安全扫描。建议把CORS头检查集成到CI/CD流水线里，用自动化工具扫描每个接口的响应头，发现通配符或者配置错误直接阻断发布。

八、未来趋势：零信任架构下的CORS演进

随着零信任安全理念的普及，CORS策略会进一步收紧。未来的方向包括：基于请求上下文的动态策略（根据用户角色、设备指纹、地理位置实时决定是否放行）、服务端主动推送策略更新（不再依赖浏览器缓存）、以及与身份提供商（IdP）的深度集成实现细粒度的跨域授权。

对于开发者来说，现在就应该养成"默认拒绝、按需开放"的习惯。不要把CORS当成一个一次性配置的东西，它应该是持续维护的安全策略的一部分。每个新接口上线前都要问自己：这个接口的数据敏感吗？谁应该能访问？用什么方式验证身份？把这三个问题回答清楚，CORS配置自然就不会出问题。

总结一句话：跨域资源共享策略收紧不是给开发添麻烦，而是在倒逼你把数据安全的责任落实到每一行代码、每一个接口、每一次部署里。把白名单做细、把认证做实、把响应做小，数据泄露的风险就能降到最低。