CORS跨域配置是端到端安全策略，需全链路审计：一查Access-Control-Allow-Origin是否白名单动态校验、禁用*；二验credentials与Set-Cookie三处闭环；三覆OPTIONS预检路径与网关透传；四查字体、WebSocket等非典型资源策略一致性。
跨域配置不是“加几个响应头就完事”的操作，它直接关系到数据泄露、CSRF放大、凭证劫持等高危风险。在全链路安全审计中，必须把 CORS 配置当作一个端到端的策略流来检查——从前端发起请求的上下文，到网关/反向代理层，再到后端服务，最后落到浏览器实际行为验证。漏掉任一环，都可能让“看似合规”的配置变成安全盲区。
一、检查 Access-Control-Allow-Origin 是否精确可控
这是最常被误配的核心头。审计时不能只看有没有这个头，而要看它是否满足最小权限原则：
- 禁止在生产环境使用 Access-Control-Allow-Origin: *，尤其当请求携带凭证（如 Cookie 或 Authorization）时，浏览器会直接拒绝该响应
- 确认后端或网关是否根据请求中的 Origin 请求头做白名单校验，而不是静态返回固定域名；动态校验需覆盖所有合法前端域名（含子域、测试环境、H5 域名等）
- 检查是否存在“Origin 反射”漏洞：比如直接 echo 请求里的 Origin 值，未做正则匹配或列表比对，攻击者可构造恶意 Origin 绕过限制
二、验证 credentials 与凭据传递是否闭环可信
带 Cookie 或 HTTP 认证的跨域请求，需要三处严格对齐：
- 前端 fetch 或 XMLHttpRequest 必须显式设置 credentials: 'include'（或 'same-origin'）
- 服务端响应头必须同时包含：Access-Control-Allow-Credentials: true + Access-Control-Allow-Origin: 具体域名（不能是 *）
- Set-Cookie 响应头本身需满足安全属性：Secure（仅 HTTPS）、SameSite=None（跨域必需）、Domain 明确限定（如 Domain=example.com，不写则默认为当前 host）
三、覆盖预检请求（OPTIONS）的真实路径与权限
很多接口在开发环境能通，上线后报错，往往卡在 OPTIONS 被拦截。审计要确认：
立即学习“Java免费学习笔记（深入）”；
- 所有可能触发预检的路径（如含自定义 Header、Content-Type: application/json、非 GET/POST 方法）是否真实响应了 200 + 正确 CORS 头
- 网关（Nginx / API Gateway / Cloudflare）是否透传或主动拦截了 OPTIONS 请求；有些网关默认不转发 OPTIONS，或鉴权中间件未放行该方法
- 后端是否将 OPTIONS 视为“无害请求”而跳过日志、监控或风控逻辑——这会导致预检绕过安全策略
四、排查非典型跨域资源的策略一致性
CORS 不只管 fetch/XHR，审计还需延伸至：
- 字体（.woff2/.ttf）和 WebGL 纹理：若通过 CSS @font-face 或 ImageBitmap 加载，需服务端返回 Access-Control-Allow-Origin，否则渲染失败或报错
- WebSocket 握手：虽然不走 CORS 协议，但浏览器仍校验 Origin 请求头，服务端必须显式校验并拒绝非法来源，否则构成跨域连接通道
- iframe 的 postMessage 通信：虽不依赖 CORS，但目标 iframe 的 sandbox 属性、allow 权限、以及源校验逻辑也属于同源策略延伸审计范围
