CORS 是什么？

核心解释

浏览器依据 Access-Control-Allow-Origin 等标头执行 CORS。通配符并不总是危险，是否合适取决于资源是否公开以及是否携带凭据。

CORS 管理的是浏览器读取跨源响应的权限

同源策略默认限制一个网页脚本读取其他来源的响应。CORS（Cross-Origin Resource Sharing）由目标服务器通过 Access-Control-Allow-* 标头选择哪些来源、方法和请求头可以被浏览器脚本访问。它是服务器放宽浏览器限制的协议，而不是防火墙或用户认证。

跨源表单提交、图片加载和服务器到服务器请求不都受相同读取限制。CORS 主要约束浏览器 JavaScript 能否获得响应内容，因此“没有 CORS”不等于接口无法被请求，“允许跨源”也不自然等于接口数据公开。

简单请求与预检请求如何不同

• 满足特定方法、标头和内容类型的简单请求可直接发送，浏览器随后根据响应中的允许来源决定是否把内容交给脚本。
• 非简单请求先发送 OPTIONS 预检，询问允许的方法、请求头和凭据；预检通过后才发送实际请求。
• Access-Control-Allow-Origin 可以是具体来源或 *；携带凭据时不能与通配符来源组合使用，服务器还应正确处理缓存的 Vary: Origin。
• Access-Control-Allow-Credentials 允许浏览器在符合条件时暴露带凭据响应，但 Cookie 是否发送还受到 SameSite、Secure 和第三方 Cookie 策略影响。

动态回显 Origin 为什么容易配置失误

为了支持多个前端，服务器可能读取 Origin 并动态返回。如果没有严格与受信任列表比较，而是反射任意来源，浏览器可能允许不受信网站读取用户有权访问的数据。字符串后缀匹配、允许 null 来源和错误处理子域都是常见风险。

正确方案需要按接口敏感度设置精确来源、方法和标头，并把认证与授权留在服务器端。CORS 不能替代访问控制；即使浏览器阻止读取，攻击者仍可能从自己的服务器直接调用公开接口。

实际应用与信息解读

评估 CORS 需要带不同 Origin 实际请求，比较简单请求与预检响应。首页没有相关标头只说明该响应没有开放跨源读取，不能推断整个 API 的策略。

发现 * 对完全公开且不带凭据的静态资源可能合理；若敏感接口反射任意来源并允许凭据，才可能形成更强风险信号。证据不覆盖 API 时应保持未知。

重点关注

错误的 CORS 配置可能让不受信任的网站读取原本应受限制的数据。

常见问题

Access-Control-Allow-Origin: * 一定危险吗？

不一定。对公开字体、图片或无需凭据的数据可能合理；风险取决于资源敏感度、凭据和其他授权控制。

CORS 能阻止别人从服务器调用 API 吗？

不能。CORS 由浏览器执行，服务器端程序不受同源策略限制，接口仍需真正的认证、授权和速率控制。

为什么预检通过但实际请求仍失败？

实际响应也必须包含匹配 CORS 标头，且认证、方法、Cookie SameSite 和业务授权都可能继续影响结果。