一个晴朗的跨域下午，某电商平台的资源安全工程师老周盯着日志里一串异常的Origin头，后背发凉。共享攻击者从evil.com发来的漏洞请求，竟然成功读取了用户收货地址。修复这不是跨域魔法，是资源CORS配置里那个星号（*）在作祟。跨域资源共享本身是共享浏览器给Web应用开的便捷通道，可一旦配错，漏洞等于把家门钥匙复制给了整条街。修复

问题出在“信任”的跨域粒度上。很多团队图省事，资源直接`Access-Control-Allow-Origin: *`，共享配合`Access-Control-Allow-Credentials: true`。漏洞这在HTTP无凭证请求时还能勉强遮掩，修复一旦带上Cookie，等于告诉任何网站：拿着用户凭证来随便读数据吧。更隐蔽的坑在预检请求——部分开发者对OPTIONS请求一律返回200，还顺手反射任意Origin。攻击者只需在自家页面发个fetch，就能绕过同源策略，把敏感接口当自家后院逛。

修复得从根上动刀。第一刀砍向配置：动态校验Origin白名单，精确到子域名，别用通配符。比如只允许`https://shop.example.com`，代码里写清楚正则或精确匹配。第二刀处理凭证：若必须携带Cookie，就把`Access-Control-Allow-Origin`设成具体来源，同时禁用`*`。第三刀是给预检请求设短缓存——`Access-Control-Max-Age`别设24小时，10分钟足够，这样即使后续改配置，旧策略也不会在用户浏览器里赖着不走。

光改配置不够，得加“验证”环节。老周后来写了个自动化测试脚本，每次发版前模拟恶意Origin（比如`https://evil.com`、`https://shop.example.com.evil.com`）去请求接口，断言响应头里没有回显这些来源。这脚本不复杂，二十几行Python的事，但能把回归风险摁死。他还顺手加了道保险：对非浏览器客户端（比如小程序、App）的请求，干脆不走CORS逻辑，因为那些环境根本不受同源策略约束——很多漏洞其实是“给不需要的人开了扇窗”。

有个细节常被忽略：错误信息泄露。某些框架在CORS校验失败时返回详细报错，比如“Origin not in whitelist: https://evil.com”。这等于帮攻击者探测白名单边界。最好统一返回403，别带具体原因。另外，Vary: Origin响应头必须加上，否则CDN缓存会把一个来源的CORS头发给另一个来源，造成交叉污染。我见过真实案例——某新闻网站图片接口因漏了Vary头，导致用户A的缓存数据被用户B读取。

修完配置别急着收工。翻翻日志，看看有没有异常的OPTIONS请求连续打同一个接口，那可能是扫描器在试探。老周修复后两周内，拦截了17次针对用户信息接口的跨域尝试，全是同一IP段。他把这些IP拉黑，又给关键接口加了额外的Referer校验——双保险。说到底，CORS漏洞修复不是改个配置就完事，它考验的是对“信任边界”的理解。你允许谁读数据，用什么方式读，读多久，都得像写合同条款一样抠字眼。

最后说句实在话：如果项目里还在用`*`加Credentials的组合，别等出事了再改。现在就去把代码里的星号删了，换成明确的域名列表。十分钟的改动，可能省掉未来一次数据泄露的公关危机。浏览器安全机制是道防线，但防线本身得靠人扎紧。