Access-Control-Allow-Origin 不能为 * 当携带凭证

Question

当浏览器发起携带凭据（如 Cookie、Authorization 头）的跨域请求时，若服务端设置 `Access-Control-Allow-Origin: *`，会导致请求失败。原因是安全策略禁止使用通配符 `*` 与凭据共存。此时需将该头改为明确的源（如 `https://example.com`），并配合设置 `Access-Control-Allow-Credentials: true`。常见于登录鉴权跨域请求中，开发者忽略此限制会导致 CORS 被拒，建议根据实际请求源动态设置允许的 Origin 值。

Answer 1

深入解析跨域请求中凭据与通配符冲突问题

1. 问题背景：CORS 与凭据的基本概念

跨域资源共享（Cross-Origin Resource Sharing, CORS）是浏览器实现的一种安全机制，用于控制一个源（origin）的前端应用能否访问另一个源的资源。当请求携带凭据（如 Cookie、Authorization 头）时，称为“带凭据请求”（credentialed request）。

此时，若服务端返回 Access-Control-Allow-Origin: *，浏览器将拒绝该响应，即使后端成功处理了请求。这是由于 W3C 的 CORS 规范明确禁止在带凭据请求中使用通配符 * 作为允许源。

2. 核心限制：为何不能共存？

安全模型设计初衷是为了防止敏感信息泄露。如果允许 Access-Control-Allow-Origin: * 同时支持凭据，则任何网站都可以通过脚本发起请求并携带用户的登录 Cookie，从而造成跨站请求伪造（CSRF）风险加剧。

因此规范要求：

• 若请求包含凭据（credentials: 'include' 或自动发送 Cookie），则 Access-Control-Allow-Origin 必须为具体源，不能为 *。
• 同时必须设置响应头：Access-Control-Allow-Credentials: true。

3. 典型错误场景再现

客户端请求	服务端响应头	浏览器行为
fetch('https://api.example.com/login', { credentials: 'include' })	Access-Control-Allow-Origin: *	拒绝响应，控制台报错 CORS 被拒
fetch('https://api.example.com/login', { headers: { Authorization: 'Bearer xxx' } })	Access-Control-Allow-Origin: *, Access-Control-Allow-Headers: Authorization	预检通过但主请求失败，因缺少 Allow-Credentials
axios.get('/profile', { withCredentials: true })	Access-Control-Allow-Origin: https://client.example.com, Access-Control-Allow-Credentials: true	成功获取数据

4. 解决方案路径图谱

解决此类问题需从服务端配置入手，结合运行时环境动态判断请求来源。以下是推荐的处理流程：

// Node.js Express 示例
app.use((req, res, next) => {
    const allowedOrigins = ['https://example.com', 'https://admin.example.org'];
    const origin = req.headers.origin;

    if (allowedOrigins.includes(origin)) {
        res.header('Access-Control-Allow-Origin', origin);
        res.header('Access-Control-Allow-Credentials', 'true');
    }

    res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
    res.header('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept, Authorization');

    if (req.method === 'OPTIONS') {
        return res.sendStatus(200);
    }

    next();
});
    

5. 动态 Origin 验证策略

为兼顾安全性与灵活性，建议采用白名单 + 正则匹配的方式动态设置 Access-Control-Allow-Origin。以下为增强版逻辑：

1. 提取请求头中的 Origin 字段。
2. 校验该源是否在预设白名单中，或符合组织内部域名模式（如 *.mycompany.com）。
3. 仅当匹配成功时，将其回写至响应头，并启用 Allow-Credentials: true。
4. 记录非法跨域尝试用于审计。
5. 避免反射任意 Origin（即直接 echo），以防被恶意站点利用。
6. 生产环境中应结合反向代理（如 Nginx、API Gateway）统一管理 CORS 策略。
7. 使用中间件封装通用逻辑，便于多服务复用。
8. 对开发环境可适度放宽，但仍建议模拟真实策略。
9. 定期审查允许的源列表，及时移除废弃域名。
10. 配合 SameSite Cookie 属性进一步加固会话安全。

6. 安全架构视角下的综合防护

除了正确配置 CORS 头外，还需构建纵深防御体系：

graph TD A[前端发起带凭据请求] --> B{服务端验证Origin} B -->|合法源| C[设置明确Allow-Origin + Allow-Credentials:true] B -->|非法源| D[返回403或默认无凭据策略] C --> E[浏览器接受响应] D --> F[阻止资源暴露] G[Cooki属性: Secure; HttpOnly; SameSite=Lax] --> A H[JWT Token存储于内存而非localStorage] --> A I[预检请求缓存: Access-Control-Max-Age] --> C

7. 常见误区与调试技巧

开发者常陷入如下陷阱：

• 误以为只要加了 Access-Control-Allow-Headers 就能解决所有问题。
• 在 Nginx 中配置了 add_header Access-Control-Allow-Origin *; 后未意识到其与凭据不兼容。
• 忽略预检请求（OPTIONS）的完整头信息配置，导致实际请求被拦截。
• 本地开发使用 http://localhost:3000 未加入白名单。

调试建议：

1. 打开浏览器开发者工具，查看 Network 面板中请求的 Request Headers 和 Response Headers。
2. 关注 Console 是否输出类似 “Credentials flag is ‘true’…” 的警告。
3. 使用 Postman 或 curl 模拟请求，绕过浏览器策略进行对比测试。
4. 检查代理层（如 CDN、负载均衡器）是否覆盖或删除了自定义头。