首页/资讯中心/详情

Access-Control-Allow-Origin 在企业中的用法

Access-Control-Allow-Origin 在企业中的用法
📅 发布时间：2026/6/21 18:57:26

接上篇文章说道，跨域解决方案中的 CORS 方案，会配置一个 Access-Control-Allow-Origin 的配置项，而且我们一般不直接配置为 *，这样做的原因是什么以及企业中的最佳实践是怎么样的，这篇文章给你答案！

简单概括

  • Access-Control-Allow-Origin: * ​允许任意来源的页面读取你的响应内容​（对浏览器端的 JS 可读性开放）。
  • ​如果响应包含敏感数据或依赖 cookie/凭证（Authorization / session）​，绝不能 用 *。因为 * 与 Access-Control-Allow-Credentials: true 不能同用，浏览器也会拒绝这种组合；但即便没有 credentials，开放读取会增加数据泄露与滥用风险。
  • 对于​公共静态资源（可公开的图片、脚本、样式）​，用 * 是可接受且常见的做法；但对​API/用户数据/鉴权资源​，企业级环境会严格限定 origin 并配合其他安全措施。

* 的具体风险

  1. 数据暴露风险任意第三方站点都能通过 AJAX 获取你的响应并在用户浏览器内读取到响应数据（如果该请求不需要 cookie）。

  2. 无法与 credentials 一起用如果你的 API 依赖 Cookie / HTTP Auth（credentials: 'include'），你不能设置 *。浏览器会阻止读取响应。

    这里我说的 credentials: 'include' 是 fetch​ 请求选项里的一个配置，用来控制 ​是否在跨域请求中携带凭证（如 Cookie、HTTP Auth(Authorization 请求头)、Client SSL 证书）​。

    当然，我们之前说过的，跨域访问的话，服务端同时需要支持 Access-Control-Allow-Credentials: true。

  3. 缓存污染与中间件问题如果你对 Origin 动态回显而未设置 Vary: Origin，中间缓存（CDN、代理）可能将一个 origin 的响应误发给另一个 origin，造成安全/隐私漏洞。

    1. Origin 是浏览器在 跨域请求 时自动携带的 ​请求头​。比如：Origin: ​https://frontend.com。
    2. Vary 是服务器的 ​缓存控制响应头​。告诉缓存系统（如 CDN、浏览器缓存、负载均衡代理），当缓存这个响应时，需要 区分哪个请求头不同 时生成不同的缓存版本。比如：Vary: Origin，不同 Origin 来访问相同 URL，缓存系统要为他们分别缓存。

详述 Origin 和 Very

鉴于很多同学在工作中，并没有非常关注过这些配置，这里再详细讲讲。

先看常见的动态回显代码：res.setHeader("Access-Control-Allow-Origin", req.headers.origin);

这表示 后端根据请求方的 Origin 动态设置 CORS 允许域名。

但是 ​如果不设置 ​Vary: Origin​：

缓存（如 CDN 或代理服务器）可能把第一个请求的响应缓存下来。举例：

  1. 用户 A（域名 a.com）访问 → 缓存：Access-Control-Allow-Origin: ​https://a.com
  2. 用户 B（域名 b.com）访问 → 本应得到：Access-Control-Allow-Origin: ​https://b.com
  3. 但由于缓存未区分，响应变成：Access-Control-Allow-Origin: ​https://a.com

=> 跨域安全事故：b.com​​ 拿到了 ​a.com​​ 的权限配置缓存

正确做法：用白名单 + Vary

const allowList = ["https://a.com", "https://b.com"];const origin = req.headers.origin;
if (allowList.includes(origin)) {res.setHeader("Access-Control-Allow-Origin", origin);res.setHeader("Access-Control-Allow-Credentials", "true");res.setHeader("Vary", "Origin");   // 关键
}

企业推荐做法

  1. 返回​具体 origin（白名单）或动态回显但要做严格白名单校验​。必要时返回 Access-Control-Allow-Credentials: true 并确保 Access-Control-Allow-Origin 为允许的具体域名而非 *。如果必须动态回显 Origin：​务必设置 ​Vary: Origin​。
  2. 对​公共静态资源（图标、CDN 上的公开脚本、字体）​：可以使用 *。例如图片、CSS、JS（仅代表不包含敏感逻辑）通常可以 *，便于 CDN 与第三方站点直接引用。
  3. 不要仅在客户端身份验证与鉴权，客户端防“君子”不防“小人”，必须​在服务器端强制检查。​不能把鉴权依赖于 CORS；CORS 只是浏览器的便利机制。对每个请求在后端都做 token/session 验证和权限检查。
  4. Cookie 策略与 SameSite（配合 CORS 使用），对跨站登录场景优先使用 SameSite=None; Secure，并在前端使用 fetch(..., credentials: 'include')。但前提是 Access-Control-Allow-Origin 不能为 *。
  5. 使用反向代理，将前端请求同域发到 Nginx（配置同上述示例中的服务端配置），然后由 proxy 转发到内部 API。这样避免 CORS 的复杂性并能统一做鉴权、限流、审计。

详述 SameSite=None; Secure

SameSite 是浏览器对 cookie 跨站发送 的限制策略，用来防止 CSRF 等跨站攻击。SameSite 有三种值：

比如：Set-Cookie: session_id=xxxx; SameSite=None; Secure; HttpOnly; Path=/

  • Secure：cookie 只能在 HTTPS 的环境中发送，而且现代浏览器必须要求：SameSite=None ➜ 必须同时带 Secure 。
  • HttpOnly：客户端 JS 无法读 cookie，防止 XSS 。
  • Path=/ ：这个 Cookie ​在整个网站（所有路径）都有效​。比如，我们的网站是 example.com ，浏览器在 example.com 域下自动设置了 Cookie（Set-Cookie 已响应），之后只要访问 example.com 这个域下的任意路径，都会自动带上它。
    • 比如：Set-Cookie: token=abc123; Path=/user，访问 /user/xxx 可以访问，但是访问 /，/api 等等的请求路径就不会携带 token 。

写到这里，有些同学就想问了，这么看来，cookie 挺好的呀，为什么后面逐渐又出现了 jwt 这种会话控制方案呢？他们的区别是什么呢？下一篇文章给你答案！