CORS 跨域配置检查
检查 Access-Control 系列响应头是否存在过度放开，重点识别带凭证的跨域读取风险。
CORS 配置检查
只做静态判断，实际跨域行为还与请求方法、预检结果和浏览器策略有关。
跨域是怎么被放行的
浏览器的同源策略默认阻止页面读取其他源的响应。CORS 是一套让服务端主动声明「允许谁来读」的机制，核心是几个以 Access-Control- 开头的响应头。服务端不加这些头，前端就算拿到数据也读不到。
简单请求直接发出，浏览器检查响应头决定是否把结果交给脚本；带自定义头或使用 PUT、DELETE 等方法的请求会先发一次 OPTIONS 预检，服务端必须正确响应预检，真实请求才会发出。
最需要警惕的组合
Access-Control-Allow-Origin: * 配合 Access-Control-Allow-Credentials: true 是明确被规范禁止的组合，浏览器会直接拒绝。但很多开发者为了让带 Cookie 的请求通过，改成回显请求方的 Origin 并同时允许携带凭证——这等于对所有站点开放了带身份凭证的读取权限，只要用户在浏览器里登录着该系统，任意恶意页面都能读到数据。这类配置在实际渗透测试中出现频率很高。
正确做法是维护一份白名单，只回显名单内的 Origin，同时对预检请求做来源校验。
响应头含义速查
| 响应头 | 作用 | 风险写法 |
|---|---|---|
| Allow-Origin | 声明允许读取的源 | 回显任意 Origin 且允许凭证 |
| Allow-Credentials | 是否允许携带 Cookie 等凭证 | 与通配符同时使用 |
| Allow-Methods | 允许的请求方法 | 包含未使用的 PUT、DELETE |
| Allow-Headers | 允许的自定义请求头 | 回显请求头列表，等于全部放开 |
| Expose-Headers | 允许脚本读取的响应头 | 暴露内部调试头 |
| Max-Age | 预检结果缓存时长 | 过长导致策略变更不生效 |
相关产品与指南
常见问题
为什么 Allow-Origin 设成 * 还是报跨域错误？▼
如果请求带了 Cookie 或 Authorization 头，浏览器要求 Allow-Credentials 为 true，而规范禁止通配符与凭证同时使用，所以会被拒绝。需要改成返回具体来源。
回显请求的 Origin 有什么风险？▼
等于对所有站点开放。如果同时允许携带凭证，用户登录状态下访问任意恶意页面，该页面都能读取接口数据。这类配置在渗透测试里很常见，属于需要优先整改的问题。
预检请求为什么一直失败？▼
常见原因有三：OPTIONS 请求没有被路由正确处理，返回了 404 或 405；Allow-Headers 没有包含实际发送的自定义头；网关或 WAF 拦截了 OPTIONS 方法。排查时先看预检的实际响应。
CORS 能防住接口被直接调用吗？▼
不能。CORS 只约束浏览器里的跨源读取，用脚本直接发请求完全不受限制。接口鉴权必须靠服务端的身份校验，CORS 只是浏览器侧的一道补充约束。
网关统一加 CORS 头要注意什么？▼
注意不要覆盖业务侧已有的配置，也不要无条件回显 Origin。网关层通常拿不到业务白名单，建议由业务侧声明允许来源，网关只做透传和兜底。