浏览器同源策略拦不住的跨域东西，CORS 算一个。漏洞很多人以为配了 Access-Control-Allow-Origin: * 就万事大吉，跨域结果数据被隔壁站点扒得一干二净。漏洞这事我见过太多次了。跨域

先说说 CORS 到底在干嘛。漏洞它本质上是跨域浏览器给服务器加的一道"信任协商"机制。浏览器发跨域请求时，漏洞会自动带上 Origin 头，跨域服务器如果回一个匹配的漏洞 Access-Control-Allow-Origin，浏览器才把响应交给前端 JS。跨域关键点在于——这个校验完全在浏览器端完成。漏洞服务器只是跨域"声明"了谁可以读，至于读的漏洞人是不是真的被信任，服务器自己根本不知道。跨域

反射 Origin：最偷懒也最危险的写法

我审计过一个内部管理后台，代码里写着：

Access-Control-Allow-Origin: [请求中的Origin值] Access-Control-Allow-Credentials: true

开发者的想法很简单：反正只允许我们自己人访问，动态回显 Origin 就行了。问题是，任何攻击者页面发起的请求，Origin 就是攻击者的域名，服务器照样原样反射回去，还附带 Credentials: true。这意味着什么？攻击者页面上的 fetch 请求可以携带受害者的 Cookie，读取管理后台的全部接口数据。

更离谱的是，有些代码只检查 Origin 里是否"包含"目标域名。比如判断 origin.includes("trusted.com")，那 trusted.com.evil.net 直接就绕过去了。这种写法我在三个不同项目里都遇到过，不是个例。

null Origin 的坑

还有个容易被忽略的场景：Origin: null。沙箱 iframe、本地 HTML 文件、某些重定向场景都会产生 null Origin。如果服务器把 null 加入了白名单——有些开发者为了图省事确实这么干——那攻击者只需要在自己页面上放一个 sandbox iframe，就能拿到跨域读取权限。这条路子比反射 Origin 隐蔽得多，因为 null 看起来"无害"。

通配符和 Credentials 的矛盾

规范里写得很清楚：Access-Control-Allow-Origin: * 和 Access-Control-Allow-Credentials: true 不能同时使用。但实际部署中，很多反向代理或中间件会自动补全头部，导致两个头同时出现在响应里。浏览器在这种情况下会直接拒绝带凭证的请求——看似安全，但如果某个接口不需要凭证就能返回敏感数据，通配符就是敞开的大门。我见过一个天气 API 返回用户绑定的手机号，就因为通配符配置，任何人嵌入一个脚本就能批量拉取。

预检请求不是安全边界

有人觉得 OPTIONS 预检能挡住攻击。预检只检查方法和头部是否被允许，不验证调用者的真实身份。攻击者只要构造一个简单请求（比如 Content-Type: text/plain 的 POST），根本不会触发预检，直接就把数据发出去了。服务器如果只依赖 CORS 头做访问控制，等于把门锁装在猫眼上。

真正靠谱的做法就一条：别把 CORS 当认证手段。敏感接口该验 Token 验 Token，该查 Session 查 Session，Origin 白名单只是额外一层，不能是唯一一层。配置的时候，精确匹配完整 Origin，别用正则、别用 includes、别反射、别加 null。这几条做到了，大部分 CORS 漏洞就跟你没关系了。

(责任编辑：娱乐)