网站安全跨域资源共享CORS严格Origin检查

CORS（Cross-Origin Resource Sharing，跨域资源共享）的核心机制就是通过HTTP响应头中的Origin字段进行严格校验，服务器收到跨域请求后会检查请求头里携带的Origin值是否在自己允许的白名单中，匹配则返回Access-Control-Allow-Origin响应头并附带资源，不匹配则直接拒绝。所谓"严格Origin检查"，就是服务器不使用通配符"*"，而是精确比对请求来源的协议、域名和端口，确保只有被明确授权的来源才能获取数据。这是目前Web安全领域防止CSRF、数据窃取和未授权访问的第一道防线。

很多开发者在配置CORS时容易犯两个错误：一是为了图省事直接设置Access-Control-Allow-Origin为"*"，二是忽略了预检请求（Preflight Request）的处理。这两个问题在生产环境中都会带来严重的安全隐患。今天这篇文章，我会从原理、配置方法、常见漏洞、最佳实践四个维度，把CORS严格Origin检查这件事讲透。

一、CORS的工作原理：为什么需要Origin检查

浏览器的同源策略（Same-Origin Policy）规定，只有协议、域名、端口三者完全相同的请求才被视为"同源"。当你的前端页面部署在https://www.example.com，而API接口在https://api.example.com，这就是跨域请求。浏览器会自动在请求头中添加Origin字段，告诉服务器"我从哪里来"。

服务器收到请求后，读取Origin值，与自身配置的允许列表进行比对。如果匹配成功，服务器在响应头中返回：

Access-Control-Allow-Origin: https://www.example.com

浏览器收到这个响应头后，才会把数据暴露给前端JavaScript代码。如果服务器返回的是通配符"*"，或者根本没有返回这个头，浏览器就会拦截响应，前端拿不到数据。

对于非简单请求（比如使用了PUT、DELETE方法，或者自定义了请求头），浏览器还会先发一个OPTIONS预检请求，询问服务器"我接下来要发的这个跨域请求你允不允许"。服务器需要在预检响应中明确告知允许的方法、头信息和凭证策略，浏览器确认后才会发送真正的请求。

二、严格Origin检查的具体实现方式

严格Origin检查的本质是服务器端动态校验。你不能写死一个固定的Origin值，而是要从请求头中读取Origin，然后做精确匹配。以下是几种主流后端框架的实现方式。

在Node.js的Express框架中，可以这样配置：

const cors = require('cors');

const allowedOrigins = [
  'https://www.example.com',
  'https://app.example.com',
  'https://admin.example.com:8080'
];

const corsOptions = {
  origin: function (origin, callback) {
    // 允许没有Origin的请求（比如服务器间调用）
    if (!origin) return callback(null, true);
    // 严格比对，必须完全匹配
    if (allowedOrigins.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']
};

app.use(cors(corsOptions));

在Java Spring Boot中，实现方式如下：

@Configuration
public class CorsConfig implements WebMvcConfigurer {

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

在Nginx层面做严格Origin检查，适合不想改动后端代码的场景：

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

        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' "$http_origin";
            add_header 'Access-Control-Allow-Credentials' 'true';
            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;
            return 204;
        }
    }
}

注意，Nginx的if指令在某些情况下可能有陷阱，生产环境建议用map指令替代：

map $http_origin $cors_origin {
    default "";
    "~*^https://(www\.example\.com|app\.example\.com)$" $http_origin;
}

server {
    location /api/ {
        add_header 'Access-Control-Allow-Origin' $cors_origin;
        add_header 'Access-Control-Allow-Credentials' 'true';
        add_header 'Vary' 'Origin';
    }
}

三、常见的CORS安全漏洞与错误配置

第一个高危问题：使用通配符"*"配合credentials: true。这在技术上是矛盾的，浏览器会直接拒绝。但更危险的是，如果你在开发阶段用了"*"忘记改回来，生产环境就等于对所有来源开放了接口，任何人都可以跨域调用你的API并读取用户数据。

第二个问题：Origin白名单配置过宽。有些开发者为了兼容多个子域名，直接写了"*.example.com"这样的通配符。但要注意，Origin字段本身不支持通配符匹配，你必须枚举每一个具体的值。如果你的子域名很多，建议在后端用正则做动态校验，而不是手动维护一个巨大的列表。

第三个问题：忽略预检请求的安全校验。OPTIONS请求本身不携带敏感数据，但如果你不对它做严格的Origin检查，攻击者可以通过发送大量OPTIONS请求来探测你的CORS策略，甚至利用某些服务器的配置缺陷绕过限制。

第四个问题：反射Origin（Reflected Origin）攻击。有些服务器会无条件地把请求头中的Origin值原样反射回Access-Control-Allow-Origin中。这意味着攻击者可以构造一个恶意页面，让受害者的浏览器携带任意Origin去请求你的接口，而服务器会"配合"地返回允许。解决办法就是前面提到的白名单比对，绝不能无脑反射。

四、严格Origin检查的最佳实践

第一，永远不要在生产环境使用通配符。开发阶段可以用，但要有明确的流程确保上线前改掉。建议用环境变量区分开发和生产的CORS配置。

第二，白名单要精确到协议、域名和端口。https://example.com和http://example.com是两个不同的Origin，example.com:80和example.com:443也是不同的。很多人忽略端口差异，导致配置后仍然报跨域错误。

第三，对OPTIONS预检请求单独做安全审计。确保预检响应不会泄露任何业务逻辑信息，并且同样执行严格的Origin校验。

第四，配合其他安全机制一起使用。CORS只是浏览器层面的防护，不能替代服务端的身份认证和授权。即使请求通过了CORS检查，后端仍然要验证Token、检查权限，防止越权访问。

第五，定期审查和更新白名单。业务发展过程中，前端部署的域名可能会变化，旧的域名要及时从白名单中移除，避免遗留的Origin被滥用。

第六，监控异常的跨域请求。在日志中记录所有被拒绝的CORS请求，分析是否有异常来源在频繁尝试访问。这可以帮助你及时发现潜在的攻击行为。

五、CORS与其他安全策略的协同关系

CORS严格Origin检查不是孤立存在的。它需要和CSP（Content Security Policy）、SameSite Cookie、X-Frame-Options等策略协同工作。比如，CSP可以限制页面能加载哪些资源，SameSite Cookie可以防止CSRF攻击中Cookie被自动携带，X-Frame-Options可以防止页面被嵌入iframe。这些策略叠加在一起，才能构建一个相对完善的Web安全体系。

另外，对于不需要跨域的场景，最好的策略就是避免跨域。通过反向代理、BFF层（Backend For Frontend）或者将前后端部署在同一个域名下，从根本上消除CORS的需求。但现实中完全避免跨域几乎不可能，所以严格的Origin检查就成了必选项。

总结一下，CORS严格Origin检查的核心就是：读取请求头中的Origin值，与服务器端维护的精确白名单做比对，匹配则放行，不匹配则拒绝。不要用通配符，不要无脑反射，不要忽略预检请求。把这些做到位，你的Web应用在跨域安全这一关就能守住底线。

网站安全跨域资源共享CORS严格Origin检查

服务指南

帮助中心