浏览器默认遵守同源策略，但是一些 web 应用采用多域协同（前端域负责页面展示，API 域负责接口 等），所以需要一个合法的跨域请求。
当浏览器发起跨域请求（比如通过 fetch / XMLHttpRequest / Ajax）时，会自动附带 Origin 头，告诉服务器请求来源。服务器通过返回特定响应头 (如 Access-Control-Allow-Origin) 来决定是否允许访问。
漏洞成因：
服务器未做严格校验
Access-Control-Allow-Origin: * 或者 动态反射 Origin 头，导致允许任意域访问敏感资源。
同时允许跨域携带凭证 (cookies / authorization header) ，Access-Control-Allow-Credentials: true 且 Access-Control-Allow-Origin 为 * 或任意域 ，导致浏览器可能允许第三方域带着用户凭证访问敏感接口。
信任 null origin 或过宽子域白名单（例如 *.example.com） →使用者可能来自攻击者控制
域 / file:// / data:// / sandbox 环境 →导致风险。
CORS 的请求分类和预检机制
简单请求 (simple request)：GET / POST / HEAD，并且请求头、Content-Type 限制在标
准值，浏览器直接发请求。
非简单请求 (non-simple / 有自定义头 / PUT / DELETE / etc.)：浏览器会先发 预检请求
(OPTIONS)，询问服务器是否允许跨域请求。只有服务器响应允许，才会继续发送真正请
求。
漏洞挖掘（BurpSuit 靶场）
实验1:具有基本起源反射的CORS漏洞
在登录时抓包，发现有Access-Control-Allow-Credentials: true 字段，说明可以读取敏感信息，然后构建 origin 字段，这里只要存在这个字段就能跨域访问，再根据提供的 js 代码，登入攻击者服务器
实验2:具有可信空源的CORS漏洞
根据题目名称以及数据包显示可知，该网站信任空源（null）.
依旧先在登陆时抓包，添加 origin 字段
漏洞防御
1. 明确定义可信白名单
不使用Access-Control-Allow-Origin: * 对敏感资源，只允许可信域访问
Access-Control-Allow-Origin: https://app.example.com
不建议使用动态反射 user-supplied Origin，除非有严格校验机制
2. 避免不安全凭证组合:
若要允许携带凭证 (cookies / authorization header)，同时不应允许所有域，仅允许固定可
信域。
浏览器规范规定：若设置 Access-Control-Allow-Credentials: true，则
Access-Control-Allow-Origin 不能为 *。
3. 对写操作 (POST, PUT, DELETE …) 做额外保护:
对敏感 / 写操作接口，不仅做 CORS 控制，还应有 CSRF Token / 二次验证机制 / 风控 /
权限校验
4. 最小化暴露接口:
对返回敏感信息 (如个人信息、支付信息、账户设置) 的接口，不应允许跨域访问
对公共资源 (静态资源 / 图片 /公共 API) 可适当放开
5. 代码 / 配置审查 & 测试:
定期 audit / review CORS 配置
渗透测试中加入 CORS misconfiguration 检查项
生产环境上线前，确保 CORS header 配置正确
6. 借助安全中间件 / WAF:
使用安全框架 / 中间件 (backend filters) 对 Origin / credentials / header / methods 做统一
检查
WAF / API Gateway 可用来强制 CORS 策略
