公共CORS配置导致敏感接口暴露风险

Question

某企业API网关采用公共CORS配置，允许所有域名（Access-Control-Allow-Origin: *）跨域请求，并支持凭据传递（withCredentials）。尽管敏感接口已做身份认证，但因CORS策略未限制具体可信源，攻击者可通过恶意站点发起预检请求并携带用户会话Cookie，成功窃取用户数据。请问：该场景下，CORS配置如何导致敏感接口暴露？存在哪些安全风险？应如何正确配置以实现最小化授权？

Answer 1

1. CORS基础机制与跨域请求流程解析

CORS（Cross-Origin Resource Sharing）是浏览器实现的一种安全策略，用于控制一个源（origin）的前端应用能否访问另一个源的资源。当浏览器发起跨域请求时，若请求包含“非简单请求”特征（如携带Cookie、使用自定义Header等），会先发送预检请求（Preflight Request），即使用OPTIONS方法询问服务器是否允许该跨域操作。

在本场景中，API网关配置了：

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

这一组合存在根本性矛盾：根据W3C规范，当Access-Control-Allow-Credentials: true时，Access-Control-Allow-Origin不能为通配符*，而必须显式指定具体源。否则，现代浏览器将拒绝响应。

响应头	允许值	限制说明
Access-Control-Allow-Origin	*	仅适用于无需凭据的请求
Access-Control-Allow-Credentials	true	必须配合具体域名，禁止使用*
Access-Control-Allow-Methods	GET, POST, OPTIONS	应最小化授权
Access-Control-Allow-Headers	Content-Type, Authorization	避免过度暴露支持头

2. 安全漏洞形成过程与攻击路径分析

尽管敏感接口进行了身份认证（如JWT或Session Cookie），但由于CORS配置不当，攻击者仍可构造恶意站点（例如：https://evil.com），通过JavaScript发起带凭据的请求：

fetch('https://api.company.com/user/profile', {
  method: 'GET',
  credentials: 'include'
});

若服务器返回Access-Control-Allow-Origin: *且Access-Control-Allow-Credentials: true，浏览器虽可能因规范限制拦截，但在某些旧版本或配置宽松环境下仍可能放行，导致用户在登录状态下被静默窃取数据。

攻击链如下所示：

graph TD A[用户登录公司系统] --> B[会话Cookie存储于浏览器] B --> C[用户访问恶意网站evil.com] C --> D[恶意JS发起带凭据的跨域请求] D --> E[API网关返回Allow-Origin:* + Allow-Credentials:true] E --> F[浏览器误判为合法响应] F --> G[敏感数据泄露]

3. 实际安全风险清单与影响评估

• 会话劫持风险：攻击者无需获取Token或Cookie明文，即可利用用户上下文发起请求。
• 信息泄露面扩大：原本受Same-Origin Policy保护的私有接口暴露给任意第三方域。
• 钓鱼攻击增强：结合社会工程学，诱导用户访问恶意页面即可完成数据窃取。
• 合规性违规：违反GDPR、网络安全等级保护等对数据访问控制的要求。
• 横向移动便利性提升：攻击者可进一步探测内部API结构，发起更深层次攻击。
• 日志混淆与溯源困难：真实请求来源被掩盖，难以区分正常调用与恶意行为。
• 供应链风险传导：若第三方集成方站点被攻陷，可间接成为攻击跳板。
• 浏览器兼容性差异引发不一致行为：部分设备/浏览器可能忽略安全限制。

4. 最小化授权原则下的CORS正确配置方案

为实现最小权限模型，建议采用以下配置策略：

1. 明确列出可信源，避免使用通配符：

2. Access-Control-Allow-Origin: https://app.company.com

3. 仅在必要时开启凭据支持，并确保Origin精确匹配：

4. Access-Control-Allow-Credentials: true

5. 限制HTTP方法范围：

6. Access-Control-Allow-Methods: GET, POST

7. 控制允许的请求头：

8. Access-Control-Allow-Headers: Content-Type, Authorization, X-Request-ID

9. 设置预检缓存时间以减少性能损耗：

10. Access-Control-Max-Age: 86400

11. 对动态请求进行源验证逻辑：

12. // 伪代码示例
    if (request.headers.get('Origin') in ALLOWED_ORIGINS) {
      response.headers.set('Access-Control-Allow-Origin', request.headers.get('Origin'));
    }

13. 启用CORS日志审计，记录所有跨域请求元数据。
14. 部署WAF规则监控异常Origin头行为。
15. 定期扫描API网关配置，检测违规CORS策略。
16. 结合OAuth 2.0或PKCE机制强化前端调用安全性。