CORS Policy严格配置跨域资源共享

原创于 2025-11-21 13:27:00 发布 · 265 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#CORS #跨域安全 #同源策略

AI助手已提取文章相关产品：

CORS Policy 严格配置：跨域安全的底层逻辑与实战精要

你有没有遇到过这样的场景？前端页面一切正常，接口在 Postman 里也能通，但一放到浏览器里就报错：

Blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

💥 崩溃三连： 我改了啥？谁动的头？这不科学啊！

别急——这不是代码写错了，而是浏览器在“保护”你。而我们要做的，不是绕过它，而是理解它、驾驭它。

现代 Web 应用早已告别“前后端一体”的时代。React、Vue 等框架让我们把前端部署在 https://app.mycompany.com ，后端 API 却跑在 https://api.mycompany.com ，甚至可能是微服务集群中的某个节点。这种架构带来了灵活性，但也触发了一个核心机制： 同源策略（Same-Origin Policy） 。

简单说，只要协议、域名、端口有任何一项不同，就被视为“不同源”。浏览器默认禁止跨源请求，防止恶意网站偷偷读取你的银行账户信息。

但现实业务又必须跨域——登录态共享、CDN 加速、微前端协作……于是 W3C 推出了 CORS（Cross-Origin Resource Sharing） ，让服务器主动告诉浏览器：“这个来源是可信的，放行吧。”

听起来很美好？可一旦配错，轻则功能失效，重则数据泄露 😱。尤其是那句看似方便的：

Access-Control-Allow-Origin: *

配上 Access-Control-Allow-Credentials: true ，简直就是把家门钥匙挂在了网上。

所以问题来了： 我们该如何既让合法请求畅通无阻，又不让黑客钻空子？答案只有一个：严格配置 CORS Policy。

浏览器是怎么判断要不要发预检的？

很多人以为 CORS 是服务器单方面决定的，其实不然。整个过程是 浏览器和服务器之间的协商 ，而且浏览器才是那个真正执行“拦截”动作的角色。

当你的 JS 发起一个跨域请求时，浏览器会先判断它是“简单请求”还是“复杂请求”。

✅ 什么是“简单请求”？

同时满足以下条件才算：

方法是 GET 、 POST 或 HEAD
请求头只能包含：
Accept
Accept-Language
Content-Language
Content-Type （且值只能是 application/x-www-form-urlencoded 、 multipart/form-data 、 text/plain ）
不使用 ReadableStream 等高级特性

比如这个请求就很“单纯”：

POST /login HTTP/1.1
Host: api.example.com
Origin: https://myapp.com
Content-Type: application/json

等等！ Content-Type: application/json ？不对哦～虽然看起来常见，但它不属于“允许的三种类型”，所以会被归为 非简单请求 ，触发预检！

🚨 小心陷阱：很多人在这里栽跟头。哪怕只是加了个 Authorization 头，或者用了 PUT 方法，都会立刻升级成“复杂请求”。

🔍 那预检请求到底发生了什么？

浏览器会在正式请求前，自动发送一个 OPTIONS 请求探路：

OPTIONS /api/user/123 HTTP/1.1
Host: api.example.com
Origin: https://myapp.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Auth-Token, Content-Type

这几个头特别关键：

Origin ：当前页面来自哪？
Access-Control-Request-Method ：我想用什么方法？
Access-Control-Request-Headers ：我还想带哪些自定义头？

服务器收到后，必须明确回应：

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: PUT, POST, GET
Access-Control-Allow-Headers: X-Auth-Token, Content-Type
Access-Control-Max-Age: 86400

只有这些都匹配，浏览器才会放行原始请求。否则直接抛出 CORS 错误——哪怕后端根本没出错。

🎯 所以你看，CORS 的本质其实是 信任链的建立过程 ，而不是简单的“开个口子”。

关键响应头详解：每一个都不能乱设

Header	作用	安全建议
`Access-Control-Allow-Origin`	允许哪个源访问	❌ 别轻易用 `*` ；✅ 白名单精确匹配
`Access-Control-Allow-Credentials`	是否允许携带 Cookie	⚠️ 若为 `true` ， `Allow-Origin` 必须具体域名
`Access-Control-Allow-Methods`	允许的方法列表	✅ 按需开放，避免 `*`
`Access-Control-Allow-Headers`	允许的请求头	✅ 明确列出，禁用通配符
`Access-Control-Max-Age`	预检结果缓存时间	✅ 建议设为 `86400` （一天），减少 OPTIONS 冗余调用
`Access-Control-Expose-Headers`	客户端可读取的响应头	✅ 如需获取 `X-Request-ID` ，必须显式暴露

这里有个经典误区：有人为了省事，直接返回：

res.header('Access-Control-Allow-Origin', req.headers.origin);

表面上看好像没问题——动态回写 Origin。但如果攻击者伪造一个 Origin: https://evil.com ，你也照样回写？那不等于开了后门？

🚫 千万不要盲目反射 Origin！正确的做法是： 先校验，再放行 。

实战代码：Express 中间件怎么写才够“严格”

来看一段真正生产级的 CORS 配置：

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

// 白名单正则，支持主站 + 子域 + 开发环境
const allowedOrigins = [
  /^https?:\/\/(?:[^.]+\.)?myapp\.com$/,
  /^https?:\/\/localhost:3000$/,
  /^https?:\/\/staging\.myapp\.com$/
];

function isValidOrigin(origin) {
  return allowedOrigins.some(pattern => pattern.test(origin));
}

app.use((req, res, next) => {
  const origin = req.headers.origin;

  if (origin && isValidOrigin(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true'); // 允许带 Cookie
  }

  // 处理预检请求
  if (req.method === 'OPTIONS') {
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, PATCH');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization, X-Auth-Token');
    res.setHeader('Access-Control-Max-Age', '86400');

    res.status(204).send();
    return;
  }

  next();
});

💡 这段代码有几个亮点：

使用正则而非字符串匹配，防止单纯的字符串比对被绕过（比如 https://myapp.com.evil.net ）
只有在 Origin 合法时才设置 Allow-Origin 和 Allow-Credentials
对 OPTIONS 请求直接返回 204，不进入后续路由处理，提升性能

前端记得配合设置：

fetch('https://api.example.com/api/data', {
  method: 'GET',
  credentials: 'include', // 必须加上才能发送 Cookie
  headers: {
    'X-Auth-Token': 'abc123'
  }
})

否则即使服务端允许凭据，浏览器也不会带上 Cookie 🤦‍♂️

常见坑点 & 最佳实践

🛑 开发环境 localhost 跨域怎么办？

别一股脑放开所有源！推荐两种安全方案：

代理转发（推荐）

js // webpack.config.js devServer: { proxy: { '/api': { target: 'http://localhost:5000', changeOrigin: true } } }

这样前端请求 /api/user ，开发服务器帮你转到后端，全程“同源”，根本不会触发 CORS。

仅开发环境启用临时白名单

js if (process.env.NODE_ENV === 'development') { allowedOrigins.push(/^http:\/\/localhost:\d+$/); }

上线前务必关闭！

🧨 凭据 + 通配符 = 安全灾难？

这是最危险的组合之一：

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

浏览器会直接拒绝这种响应，因为这意味着任何网站都可以以你的身份发起带 Cookie 的请求，CSRF 攻击分分钟上线。

✅ 正确姿势：

要么不用凭据 → Allow-Origin: * 可用
要么用凭据 → Allow-Origin 必须是具体域名

更进一步的安全建议：

优先使用 Token 认证（如 JWT），避免依赖 Cookie
结合 CSRF Token 双重验证
在网关层统一拦截非法 Origin 请求并记录日志

🔄 微服务/微前端场景如何管理？

多个团队共用一套 API，每个前端都有自己的域名。这时候可以：

在 API 网关（如 Nginx、Kong、Traefik）统一做 CORS 控制
维护一份中心化的 Origin 白名单配置
对异常 Origin 请求打日志，用于审计追踪

例如 Nginx 配置片段：

location /api/ {
  if ($http_origin ~* (https?://(.*\.)?myapp\.com|https://localhost:3000)) {
    set $cors "true";
  }

  if ($cors = "true") {
    add_header 'Access-Control-Allow-Origin' "$http_origin" always;
    add_header 'Access-Control-Allow-Credentials' 'true' always;
  }

  if ($request_method = 'OPTIONS') {
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE' always;
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
    add_header 'Access-Control-Max-Age' '86400' always;
    return 204;
  }
}