网站框架中的CORS跨域策略与预检请求安全

当你把前端代码和后端接口分别部署在不同的域名下，浏览器控制台经常会毫不留情地抛出一串红字：Access to fetch at 'https://api.yourdomain.com' from origin 'https://www.yourdomain.com' has been blocked by CORS policy。很多人第一反应是后端没返回数据，其实数据已经回来了，只是浏览器出于安全机制，把响应内容拦在了你的JavaScript代码之外。这就是跨域资源共享（CORS）策略在起作用，而它背后还藏着一个容易被忽视的环节——预检请求（Preflight Request），这个机制如果处理不当，会让你的接口响应时间凭空增加数百毫秒，甚至在高并发场景下压垮服务器。

浏览器的同源策略规定，只有当协议、域名和端口三者完全一致时，一个源加载的脚本才能去读取另一个源的资源。注意这里的关键词是“读取”。你完全可以用img标签加载一张跨域图片，用script标签引入一个跨域JS文件，这些都属于“嵌入”，不涉及读取内容。但只要你用XMLHttpRequest或者Fetch API去获取跨域接口返回的数据，浏览器就会介入检查。这个策略的初衷是防止恶意网站通过用户浏览器去窃取银行、邮箱等敏感信息，属于浏览器安全模型的核心支柱。

CORS的出现并不是要推翻同源策略，而是提供一种受控的例外机制。它通过一组HTTP响应头，让服务器明确告诉浏览器：我允许来自某个源的请求，我允许携带哪些请求头，我允许哪些HTTP方法，我允许响应在客户端缓存多久。浏览器拿到这些响应头后，才会把数据真正交给你的前端代码。

浏览器把跨域请求分成了两类，这个分类直接决定了是否会触发预检请求。简单请求必须同时满足三个条件：请求方法只能是GET、HEAD或POST三者之一；请求头只能包含Accept、Accept-Language、Content-Language以及值为application/x-www-form-urlencoded、multipart/form-data或text/plain的Content-Type；没有使用ReadableStream对象。如果你用POST发送JSON数据，Content-Type设成application/json，这个请求就不再是简单请求了，它会自动变成复杂请求。

复杂请求在正式请求发出之前，浏览器会先发送一个OPTIONS方法的HTTP请求到同样的URL，这就是预检请求。预检请求的作用是向服务器确认：我能不能用这个方法来请求这个资源？我能带哪些自定义请求头？服务器需要在预检请求的响应中明确回答这些问题，浏览器才会放行后续的正式请求。这个过程完全由浏览器自动完成，前端代码不需要做任何额外操作，但后端必须正确响应OPTIONS请求，否则整个流程就会中断。

除了上面提到的Content-Type为application/json之外，还有很多情况会触发预检请求。比如你添加了Authorization、X-Requested-With这类自定义请求头，或者你使用了PUT、DELETE、PATCH这些非简单方法，又或者你在Fetch API中设置了credentials: 'include'想要携带Cookie。实际开发中，前后端分离架构下几乎所有的业务接口都会携带token进行身份认证，这个token通常放在Authorization头里，所以绝大多数业务请求都会触发预检。

还有一个容易被忽略的场景是，即使你的请求方法和请求头都符合简单请求条件，但如果你在XMLHttpRequest对象上注册了upload事件监听器，或者使用了ReadableStream，请求也会被标记为复杂请求。这些细节在排查CORS问题时经常被遗漏，导致开发者反复检查请求头和方法却找不到原因。

处理CORS的核心工作在后端。对于简单请求，服务器只需要在响应中加上Access-Control-Allow-Origin头，值可以是指定的源，比如https://www.yourdomain.com，也可以是星号表示允许所有源。但如果请求携带了身份凭证（Cookie或Authorization头），星号就不允许使用了，必须明确指定源，同时还需要加上Access-Control-Allow-Credentials: true。

对于预检请求，服务器需要返回的信息更多。Access-Control-Allow-Methods告诉浏览器允许哪些HTTP方法，Access-Control-Allow-Headers告诉浏览器允许携带哪些请求头，Access-Control-Max-Age告诉浏览器这个预检结果可以缓存多久，单位是秒。合理设置Max-Age可以显著减少预检请求的次数，比如设置成86400秒也就是24小时，浏览器在有效期内就不会对相同URL的同类请求再次发送预检。下面是一个典型的Nginx配置示例：

location /api/ {
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://www.yourdomain.com';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, PATCH, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, X-Requested-With';
        add_header 'Access-Control-Allow-Credentials' 'true';
        add_header 'Access-Control-Max-Age' 86400;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
    }
    add_header 'Access-Control-Allow-Origin' 'https://www.yourdomain.com';
    add_header 'Access-Control-Allow-Credentials' 'true';
}

这段配置的关键在于用if指令拦截OPTIONS请求并直接返回204状态码，避免预检请求穿透到后端应用服务器，减轻业务逻辑的压力。同时为正式请求也添加了必要的CORS头，确保浏览器能正常读取响应数据。

预检请求本质上是一次额外的HTTP往返，在网络延迟较高的移动端场景下，这个开销可能达到几百毫秒。如果你的单页应用在首屏需要同时调用多个不同域名的API，每个API的第一次请求都会触发预检，这些预检请求虽然可以并行发出，但每一个都增加了连接建立和TLS握手的时间成本。

优化策略可以从几个方向入手。第一个方向是合理设置Access-Control-Max-Age，把预检结果缓存起来。但需要注意，不同浏览器对这个值的上限限制不同，Chromium内核的浏览器最大支持86400秒，Firefox最大支持86400秒，Safari则完全不支持这个头，每次都会发送预检。所以这个优化对Safari用户无效，你需要根据用户浏览器分布来评估实际收益。

第二个方向是减少触发预检的条件。如果你的API设计允许，可以把POST JSON改成POST表单格式，这样Content-Type就回到了简单请求的范畴。但这种方式会牺牲数据结构的表现力，对于复杂嵌套数据不太友好。更实际的做法是尽量避免添加不必要的自定义请求头，比如有些团队习惯加X-Client-Version之类的头来追踪客户端版本，这些信息完全可以放到URL参数或者请求体里传递。

第三个方向是架构层面的调整，把前端静态资源和后端API部署在同一个主域名下，通过反向代理把API路径转发到后端服务。这样从浏览器的视角看，所有请求都是同源的，CORS问题根本不会出现，预检请求也完全不存在。Nginx配置示例如下：

server {
    listen 443 ssl;
    server_name www.yourdomain.com;
    
    location / {
        root /var/www/frontend;
        try_files $uri $uri/ /index.html;
    }
    
    location /api/ {
        proxy_pass http://backend-server:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这种方案把CORS问题从根源上消除，性能最优，但要求你有权限统一管理域名和反向代理配置。

很多开发者在被CORS折磨几次之后，会走向另一个极端：把Access-Control-Allow-Origin设置成星号，Access-Control-Allow-Methods设置成星号，Access-Control-Allow-Headers设置成星号，甚至把Access-Control-Allow-Credentials设成true的同时还把Origin设成星号。浏览器会直接拒绝这种组合，因为允许携带凭证时Origin不能是通配符，这是规范明确禁止的。更危险的是，有些开发者会在后端代码里动态读取请求头中的Origin值，然后原样设置到Access-Control-Allow-Origin中，这种做法等于允许任意来源访问你的API，完全绕过了CORS的安全保护。

正确的做法是维护一个允许的源列表，后端在收到请求时检查Origin是否在列表中，在列表内才返回对应的Access-Control-Allow-Origin头。对于公开API，可以允许任意源访问，但这时就不要设置Access-Control-Allow-Credentials，也不要依赖Cookie或HTTP基础认证来保护接口安全，改用token放在请求头或请求体里来验证身份。

CORS和CSRF（跨站请求伪造）经常被放在一起讨论，但它们解决的问题不同。CSRF攻击利用的是浏览器会自动携带目标站点的Cookie这一特性，攻击者诱导用户点击链接或提交表单，以用户身份执行非预期操作。CORS并不能直接防御CSRF，因为简单请求不会触发预检，攻击者仍然可以通过构造表单提交来发起跨域请求。真正防御CSRF需要依赖CSRF Token、SameSite Cookie属性或者验证Referer/Origin请求头等手段。

不过CORS的预检机制确实间接增强了安全性。对于复杂请求，攻击者无法通过简单的表单提交来触发，因为表单只能发出GET和POST请求，且Content-Type受限。如果你的敏感操作都使用PUT、DELETE方法或者要求application/json的Content-Type，那么这些接口天然就会触发预检，攻击者无法在跨域场景下成功调用。这也是为什么推荐把数据修改类接口设计成JSON格式并使用非GET方法的原因之一。

遇到CORS报错时，第一步是打开浏览器开发者工具的Network面板，找到被拦截的请求，查看它的请求方法和请求头。如果请求方法是OPTIONS，说明预检请求发出了，检查响应状态码和响应头是否包含必要的CORS字段。如果OPTIONS请求本身返回了4xx或5xx状态码，预检就失败了，正式请求根本不会发出。很多后端框架默认没有处理OPTIONS路由，需要手动注册。

如果OPTIONS请求成功但正式请求仍然报CORS错误，对比预检响应中声明的Allow-Methods和Allow-Headers是否覆盖了正式请求使用的方法和头。一个常见错误是预检响应里写了Allow-Headers: Authorization，但正式请求里还带了一个X-Request-Id头，这个头没有被声明允许，浏览器就会拦截。另一个常见错误是响应头的大小写问题，虽然HTTP头名称在规范中是不区分大小写的，但有些浏览器的CORS实现对此比较敏感，建议统一使用规范的大小写格式。

如果所有响应头都正确，检查Access-Control-Allow-Origin的值是否与请求中的Origin完全匹配，包括协议和端口。http和https是不同的源，localhost和127.0.0.1也是不同的源。另外注意Access-Control-Allow-Credentials为true时，Access-Control-Allow-Origin不能是星号，必须是具体的源，否则浏览器会静默忽略这个响应头。

现代Web框架几乎都提供了CORS中间件来简化配置。以Node.js的Express框架为例，使用cors中间件可以灵活配置：

const cors = require('cors');
const express = require('express');
const app = express();

const allowedOrigins = ['https://www.yourdomain.com', 'https://app.yourdomain.com'];

const corsOptions = {
  origin: function (origin, callback) {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true,
  maxAge: 86400
};

app.use(cors(corsOptions));

这个配置动态校验Origin，只允许列表中的源访问，同时设置了预检缓存时间为24小时。对于不需要处理预检的静态资源路径，可以单独配置更宽松的策略。Spring Boot项目中可以通过添加@CrossOrigin注解或者配置WebMvcConfigurer来全局处理，Django项目可以使用django-cors-headers包，配置方式类似，核心都是设置允许的源、方法、头和缓存时间。

理解CORS和预检请求的运作机制，本质上是在理解浏览器安全模型和HTTP协议之间的协作关系。它不是前端或后端单方面的问题，而是一个需要两端配合的系统设计问题。把同源策略、简单请求判定、预检请求触发条件、响应头配置、性能优化和安全边界这些环节都理清楚，你就能在设计系统架构时做出更合理的决策，而不是每次遇到CORS报错就临时去搜索解决方案然后复制粘贴。真正扎实的做法是根据业务场景选择最合适的跨域方案，无论是CORS配置、反向代理还是JSONP，每种方案都有其适用边界和代价，理解这些边界比记住配置代码更重要。