去年秋天，信任一个做安全测试的任意朋友给我发来截图。他打开某电商网站的源漏开发者工具，在控制台里敲了三行代码，信任就把用户收货地址、任意手机号、源漏订单记录全抓了出来。信任整个过程没触发任何风控，任意服务器老老实实把数据吐给了他。源漏问题出在响应头里那行 Access-Control-Allow-Origin: *。信任

这就是任意 CORS 信任任意来源漏洞。服务器告诉浏览器："谁都可以来读我的源漏数据。"浏览器照做了。信任

浏览器原本拦得住，任意是源漏服务器自己开了门

同源策略是浏览器的基本防线。a.com 的页面默认不能读取 b.com 的接口返回内容。CORS 是一套官方放行机制，服务器主动声明"我允许某来源跨域读我"。

问题在于，很多开发者图省事，直接把允许来源写成星号。星号的意思是：任何网站、任何脚本、任何人，都能从浏览器里跨域读取这个接口的数据。

更麻烦的是，带 Cookie 的请求遇到星号时，浏览器会拒绝发送凭证。有些后端开发者为了"解决"这个问题，动态回显请求头里的 Origin 值，同时设置 Access-Control-Allow-Credentials: true。这等于说："谁问我，我就信任谁。"攻击者只需要在自己的恶意页面上发起请求，Origin 就是他的域名，服务器照样回显、照样放行、照样带上受害者的 Cookie。

一个真实场景

假设某银行有一个接口 /api/user/profile，返回当前登录用户的姓名、身份证号、余额。后端设置了动态回显 Origin 加允许凭证。

攻击者做一个钓鱼页面，里面藏一段 fetch 请求，指向这个银行接口。受害者只要在登录银行的状态下访问了钓鱼页面，浏览器就会带着银行的 Cookie 发出请求。服务器看到 Origin 是攻击者的域名，回显它，允许携带凭证。数据返回后，攻击者的 JavaScript 直接读取响应内容，通过 POST 发到自己的服务器。

整个过程受害者看不到任何异常。页面可能只是一个"加载中"的空白页。

为什么这种漏洞反复出现

我翻过不少漏洞报告，发现几个共性。一是开发阶段为了方便联调，直接放开所有来源，上线时忘了收。二是中间件或框架的默认配置过于宽松，开发者没意识到需要覆盖。三是有些团队把 CORS 当成"跨域问题的解决方案"，而不是"需要精确控制的信任策略"。

还有个认知偏差：很多人觉得 CORS 是浏览器的事，跟服务器安全无关。实际上，CORS 配置错误是把服务器数据的读取权限交给了任意网页。它不是浏览器漏洞，是服务器自己签发的通行证。

怎么判断和修复

检查方法很直接。打开浏览器开发者工具，看目标接口的响应头。Access-Control-Allow-Origin 如果是 *，且接口涉及敏感数据，就有问题。如果是动态回显你的 Origin，再配上 Access-Control-Allow-Credentials: true，问题更严重。

修复思路也简单：维护一个白名单，只允许已知的、可控的来源。不要用正则去匹配 Origin，除非你非常确定正则不会被绕过。比如 *.example.com 这种规则，攻击者可以注册 evil-example.com 来碰瓷。精确列出域名，别偷懒。

如果接口本身不需要跨域访问，直接不返回 CORS 头。如果需要，限制方法、限制头、限制来源，把信任范围压到最小。

我见过一个团队的做法值得参考：他们把 CORS 配置写进 CI 流程，每次发布前自动扫描响应头，发现星号或动态回显就阻断构建。这比事后补救有效得多。

CORS 不是用来"解决跨域"的万能钥匙。它是一份信任声明。写星号的时候，等于把家门钥匙插在锁上，还贴了张纸条告诉路人地址。