CORS 配置错误入门

Sat, 29 Aug 2026 07:35:00 +0800

写在前面：合法学习边界

本文讲解 CORS 配置错误的原理与防御。所有验证都应在自建靶场或明确授权环境中完成。请不要把敏感凭证、Cookie 或接口数据用于未授权跨域测试。

一、什么是 CORS

CORS（跨域资源共享）让浏览器在安全控制下允许跨域请求。默认情况下，浏览器遵循同源策略，限制不同源之间读取响应。

同源包括：

1
2
3


协议
域名
端口

例如 http://a.com 和 https://a.com 就不是同源。

二、CORS 的核心响应头

常见响应头：

1
2
3
4
5


Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Max-Age

其中最重要的是：

1
2


Allow-Origin：允许哪个源访问
Allow-Credentials：是否允许携带 Cookie、HTTP Auth 等凭证

三、常见错误配置

1. 允许所有来源并携带凭证

如果配置成允许任意来源，并允许凭证，风险会非常高。

2. 直接回显 Origin

服务端把客户端传来的 Origin 直接写回 Access-Control-Allow-Origin，可能导致浏览器放行不该访问的请求。

3. 没有校验凭证场景

涉及登录态、Cookie、用户数据的接口不能随便允许跨域。

四、风险怎么判断

CORS 不是“跨域请求本身危险”，关键看：

1
2
3
4


是否能跨域读取敏感响应
是否能携带用户凭证
是否返回敏感数据
接口是否具备业务影响

如果只是跨域请求公开静态资源，风险通常低。

影响与危害

CORS 配置错误能造成：

1
2
3


跨站读取用户数据（凭证被带上的情况下）
接口被第三方站点滥用
钓鱼与数据泄露

风险等级：中到高。

五、防御建议

1
2
3
4
5
6


只允许明确的来源白名单
不要对所有源使用通配符
涉及凭证时避免通配源
服务端校验 Origin
最小化允许方法
记录异常跨域访问

修复

1
2
3
4


不直接反射 Origin，使用固定白名单
Access-Control-Allow-Credentials 与白名单配合
区分内部/外部接口的跨域策略
修复后复测：非白名单 Origin 拿不到响应

验证操作步骤

1
2
3
4


第 1 步：抓接口响应，看 Access-Control-Allow-Origin
第 2 步：带自定义 Origin 重放，看是否回显
第 3 步：对带凭证接口验证 Allow-Credentials
第 4 步：能跨域读到敏感响应即确认

六、报告中的正确写法

示例：

1
2
3


发现：/api/profile 返回 Access-Control-Allow-Origin 回显客户端 Origin，并允许携带凭证。
风险：可能导致第三方站点在用户已登录时读取敏感接口响应。
建议：改为来源白名单；凭证接口禁止通配源；服务端校验 Origin；增加日志告警。

七、小结

CORS 的核心不是“要不要跨域”，而是“哪个源、带不带凭证、能不能读取敏感响应”。配置时要默认拒绝，再按需放行。

CORS on SoulJian小站