网站开发框架跨域资源共享CORS安全白名单设置

CORS（Cross-Origin Resource Sharing，跨域资源共享）安全白名单的核心就是：在服务端明确指定哪些来源（Origin）的请求被允许访问你的接口资源，而不是简单粗暴地设置为通配符"*"。很多开发者在项目上线时为了图省事，直接把Access-Control-Allow-Origin设为"*"，这在生产环境中等于把大门敞开，任何人都能跨域调用你的API，带来数据泄露、CSRF攻击等严重安全隐患。正确做法是建立一份严格的白名单，只允许你信任的域名发起跨域请求，同时配合其他安全响应头形成完整的防护体系。

要理解CORS白名单怎么设，首先得搞清楚浏览器的同源策略。同源是指协议、域名、端口三者完全一致。比如你的前端页面部署在https://www.example.com，而后端API在https://api.example.com，虽然都是example.com，但子域名不同，浏览器就认为是跨域请求。这时候如果后端不返回正确的CORS响应头，浏览器会直接拦截响应数据，前端拿不到任何结果。

CORS白名单本质上是服务端维护的一份"可信来源列表"。当浏览器发送跨域请求时，会在请求头中自动带上Origin字段，告诉服务端"我从哪里来"。服务端收到请求后，检查这个Origin是否在白名单中，如果在，就在响应头中返回Access-Control-Allow-Origin: 具体的Origin值；如果不在，就不返回这个头或者返回拒绝。浏览器根据响应头决定是否把数据交给前端JavaScript。

白名单和通配符的区别非常关键。通配符"*"意味着任何来源都能访问，适合纯公开的静态资源CDN，但绝对不适合涉及用户数据、认证信息的API接口。白名单则是精确控制，比如你只允许https://www.example.com和https://app.example.com这两个域名访问，其他任何来源一律拒绝。这种精确控制才是安全的基础。

不同的后端框架有不同的CORS配置方式，下面逐一讲解主流框架的实现。

在Node.js的Express框架中，最常用的是cors中间件。安装方式是npm install cors，然后在代码中配置白名单：

const cors = require('cors');

const corsOptions = {
  origin: function (origin, callback) {
    // 允许没有Origin的请求（比如Postman、curl等工具）
    if (!origin) return callback(null, true);
    
    // 白名单列表
    const whitelist = [
      'https://www.example.com',
      'https://app.example.com',
      'https://admin.example.com'
    ];
    
    if (whitelist.indexOf(origin) !== -1) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization', 'X-Requested-With']
};

app.use(cors(corsOptions));

在Spring Boot（Java）框架中，可以通过实现WebMvcConfigurer接口来配置：

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/")
                .allowedOrigins(
                    "https://www.example.com",
                    "https://app.example.com",
                    "https://admin.example.com"
                )
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

在Python的Django框架中，使用django-cors-headers库：

# settings.py
INSTALLED_APPS = [
    ...
    'corsheaders',
]

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    ...
]

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

CORS_ALLOW_CREDENTIALS = True

在.NET Core中，可以在Startup.cs或Program.cs中配置：

builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowSpecificOrigins", policy =>
    {
        policy.WithOrigins(
            "https://www.example.com",
            "https://app.example.com"
        )
        .AllowAnyMethod()
        .AllowAnyHeader()
        .AllowCredentials();
    });
});

app.UseCors("AllowSpecificOrigins");

第一，永远不要在生产环境使用通配符。开发阶段可以临时用"*"方便调试，但上线前必须替换为具体域名列表。第二，白名单要精确到协议和端口。https://www.example.com和http://www.example.com是两个不同的Origin，http://www.example.com:8080和http://www.example.com也不一样，必须逐一列出。

第三，要考虑子域名的情况。如果你的业务涉及多个子域名，比如www、app、admin、m，每个都需要单独加入白名单。有些团队会用正则匹配来简化配置，但要注意正则写得不严谨反而会引入安全漏洞。建议直接枚举，宁可多写几行也不要用过于宽泛的正则。

第四，配合credentials设置。当你的接口需要携带Cookie或认证信息时，必须设置Access-Control-Allow-Credentials: true，同时Origin不能是通配符，必须是具体的单个Origin值。这是浏览器的强制要求，也是防止凭证泄露的重要机制。

光设置Origin白名单还不够，一个安全的CORS策略需要多个响应头协同工作。以下是推荐的完整配置：

Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 3600
Access-Control-Expose-Headers: X-Total-Count, X-Page-Number

逐个解释：Allow-Methods限定允许的HTTP方法，不要用"*"，只开放你实际需要的方法；Allow-Headers限定前端可以发送哪些自定义请求头；Max-Age告诉浏览器预检请求的缓存时间，减少不必要的OPTIONS请求；Expose-Headers让前端JavaScript能读取到你指定的响应头信息。

浏览器在发送某些跨域请求之前，会先发一个OPTIONS方法的预检请求，用来探测服务端是否允许实际请求。这个预检请求的处理也必须纳入白名单逻辑。很多开发者只处理了实际请求的CORS头，忽略了OPTIONS请求，导致跨域调用直接失败。

正确做法是让框架自动处理OPTIONS请求，或者手动拦截OPTIONS请求并返回正确的CORS响应头。在Express中，cors中间件会自动处理；在Spring Boot中，addCorsMappings默认也会处理OPTIONS；但如果你用了自定义的过滤器或拦截器，就需要确保OPTIONS请求能正确通过。

在实际项目中，白名单不应该硬编码在代码里。推荐的做法是把白名单放到环境变量或配置文件中，比如：

# .env文件
CORS_ORIGINS=https://www.example.com,https://app.example.com,https://admin.example.com

# 代码中读取
const origins = process.env.CORS_ORIGINS.split(',');

这样做的好处是不同环境（开发、测试、生产）可以使用不同的白名单，而且修改白名单不需要重新部署代码，只需要更新配置即可。对于微服务架构，可以把白名单配置放到配置中心统一管理。

误区一：认为只要后端设置了CORS头就安全了。实际上CORS是浏览器层面的限制，攻击者可以用服务器端工具绕过浏览器直接发请求，所以后端的身份认证、权限校验、输入验证一样都不能少。

误区二：认为白名单设了就万事大吉。如果你的白名单中包含了一个被攻破的子域名，或者一个存在开放重定向漏洞的页面，攻击者可以利用这些间接实现跨域攻击。所以白名单的维护需要定期审计。

误区三：忽略了Vary: Origin响应头。当你根据不同Origin动态返回不同的Allow-Origin值时，必须加上Vary: Origin，否则CDN或代理缓存可能会把一个Origin的响应错误地返回给另一个Origin的请求。

在生产环境中，建议把CORS配置放在反向代理层（如Nginx）而不是应用层。Nginx处理CORS的性能更好，而且可以在请求到达应用之前就拦截掉非法来源。Nginx配置示例：

server {
    location /api/ {
        if ($http_origin ~* "^https://(www|app|admin)\.example\.com$") {
            add_header 'Access-Control-Allow-Origin' "$http_origin";
            add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
            add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
            add_header 'Access-Control-Allow-Credentials' 'true';
            add_header 'Vary' 'Origin';
        }
        
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' "$http_origin";
            add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
            add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
            add_header 'Access-Control-Max-Age' 3600;
            add_header 'Content-Length' 0;
            return 204;
        }
    }
}

这种方式的优势在于：第一，性能高，Nginx处理静态响应比应用服务器快得多；第二，安全边界前移，非法请求在到达应用之前就被拒绝；第三，配置集中管理，方便运维。

最后总结一下，CORS安全白名单不是一个简单的配置项，而是一套完整的安全策略。从白名单的精确设定、响应头的完整配置、预检请求的正确处理，到动态管理和生产部署，每个环节都需要认真对待。把CORS当成安全体系的一部分而不是一个孤立的功能，才能真正保护你的接口资源不被滥用。