引言
在现代 Web 应用架构中，前后端分离和微服务已成为主流开发模式，跨域资源共享（Cross-Origin Resource Sharing，CORS）因此成为浏览器安全机制中不可回避的一环。CORS 本是为突破同源策略限制而设计的标准化方案，但若配置不当，它不仅无法保护用户数据，反而会沦为攻击者窃取敏感信息的通道。本文将从漏洞原理、常见错误配置、攻击手法、真实案例及防御策略五个维度，系统分析 CORS 配置错误导致的跨域数据窃取漏洞。
一、CORS 机制回顾
同源策略规定，浏览器只允许页面脚本访问与当前页面同源（协议、域名、端口完全一致）的资源。CORS 则通过一系列 HTTP 响应头，允许服务器声明哪些外部源可以访问其资源。
关键响应头包括：
- Access-Control-Allow-Origin（ACAO）：指定允许访问的源，可为具体源或
*。 - Access-Control-Allow-Credentials（ACAC）：是否允许携带 Cookie 等凭据，值为
true或false。 - Access-Control-Allow-Methods：允许的 HTTP 方法。
- Access-Control-Allow-Headers：允许的自定义请求头。
浏览器在发送跨域请求时，会根据请求是否携带凭据、是否为简单请求，决定是否先发送预检请求（OPTIONS）。服务器返回的 CORS 头若与请求不匹配，浏览器将拦截响应，拒绝将数据交给页面脚本。
二、常见错误配置类型
1. ACAO 反射任意 Origin
最危险的配置之一，是服务器直接将请求头中的 Origin 值原样写入 Access-Control-Allow-Origin，同时设置 Access-Control-Allow-Credentials: true。例如：
Origin: https://evil.com
Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true
此时，攻击者页面 evil.com 即可携带受害者 Cookie 发起跨域请求，并读取响应内容，等同于完全绕过同源策略。
2. 信任 null Origin
部分应用为兼容本地文件或沙箱 iframe，允许 Origin: null。攻击者可通过 <iframe sandbox> 或 data: URL 构造 null 源页面，从而绕过限制。
3. 后缀/前缀匹配缺陷
开发者常使用字符串匹配判断来源，例如 origin.endsWith("trusted.com")。攻击者注册 eviltrusted.com 即可通过校验。类似地，startsWith 匹配也可能被 trusted.com.evil.com 绕过。
4. 通配符与凭据共存
规范禁止 ACAO: * 与 ACAC: true 同时使用，但部分框架或中间件在配置时可能忽略此限制，或通过动态反射变相实现，导致任意源均可携带凭据访问。
5. 内网应用过度信任
内部管理系统常假设“内网即安全”，配置 ACAO: * 且不校验来源。攻击者若通过钓鱼或 SSRF 让受害者浏览器访问内网接口，即可读取敏感数据。
三、攻击手法与利用链
1. 基本数据窃取
攻击者诱导已登录目标站点的用户访问恶意页面。页面脚本使用 fetch 携带 credentials: 'include' 向目标 API 发起请求。若 CORS 配置错误，浏览器将响应交给脚本，攻击者即可读取用户订单、个人信息、Token 等。
2. 结合 XSS 的复合攻击
若目标站点存在 XSS，攻击者可直接在目标域内发起请求，完全绕过 CORS。但即便没有 XSS，仅凭 CORS 错误配置也足以完成跨域读取，危害面更广。
3. 预检请求绕过
部分开发者仅对简单请求做来源校验，忽略 OPTIONS 预检请求的处理，导致攻击者通过构造非简单请求触发预检时，服务器返回宽松的 CORS 头，从而完成攻击。
4. 缓存投毒放大影响
若 CDN 或反向代理缓存了带有错误 ACAO 头的响应，攻击者可将该响应缓存后供其他用户使用，进一步扩大数据泄露范围。
四、真实案例
- 某在线教育平台：API 接口反射任意 Origin 并允许凭据，攻击者可读取用户姓名、手机号、课程订单。
- 某金融类 App 后端：使用
endsWith校验来源，攻击者注册相似域名后成功窃取用户资产信息。 - 某企业内部系统：配置
ACAO: *且未鉴权，配合 SSRF 可读取内网员工通讯录。
这些案例的共同点是：开发者将 CORS 视为“开关”而非“策略”，只求功能可用，忽视安全边界。
五、防御策略
1. 白名单严格校验
维护明确的来源白名单，使用精确匹配（如 ===）而非字符串包含判断。对 Origin 缺失或为 null 的请求，默认拒绝携带凭据的跨域访问。
2. 避免反射 Origin
除非经过严格校验，否则不要将请求中的 Origin 直接写入响应头。推荐使用框架提供的 CORS 中间件，并显式配置允许的来源列表。
3. 谨慎使用凭据
若业务无需跨域携带 Cookie，应设置 ACAC: false，并避免使用 ACAO: *。若必须携带凭据，则 ACAO 必须为具体源，且该源需经过严格验证。
4. 区分内外网策略
内部接口不应默认信任内网来源。建议统一走网关鉴权，CORS 策略与身份认证解耦，避免“内网即信任”的思维定式。
5. 安全测试与监控
在 CI/CD 中集成 CORS 配置检查，使用自动化工具扫描 ACAO 反射、null 源、通配符与凭据共存等问题。同时监控异常跨域请求，及时发现利用行为。
6. 最小化暴露面
敏感接口应优先采用 SameSite Cookie、CSRF Token 等机制，降低对 CORS 的依赖。对于必须跨域的场景，尽量使用后端代理而非直接暴露 API。
结语
CORS 配置错误看似只是“多写了一个头”，实则可能直接导致用户数据被任意网站读取。其危害不亚于 XSS 或 CSRF，却常因“功能正常”而被忽视。开发者应深入理解 CORS 的每一项头字段含义，遵循白名单、最小权限和默认拒绝原则，将跨域策略纳入安全开发生命周期。唯有如此，才能在享受前后端分离便利的同时，守住用户数据的边界。
未经允许不得转载：任鹏个人博客 » CORS 配置错误导致的跨域数据窃取漏洞分析
