如何查找HTML静态网页中的跨域资源共享漏洞-html教程-PHP中文网

存在cors漏洞的关键是后端接口响应头中access-control-allow-origin值为*且含access-control-allow-credentials:true，或反射可控origin；需通过devtools抓取实际跨域请求并检查响应头，而非仅扫描html源码。

如何查找html静态网页中的跨域资源共享漏洞

静态网页本身不产生 CORS 响应头，真正决定是否存在漏洞的是它所请求的后端接口（比如 /api/user、/data.json）。所以“查 HTML 中的 CORS 漏洞”本质是：用浏览器开发者工具抓取它发出的所有跨域请求，逐个检查响应头。

常见误判点：只扫 HTML 源码找 script 或 fetch 调用，却忽略实际请求是否真的跨域、以及服务端是否返回了宽松的 Access-Control-Allow-Origin。

打开 DevTools → Network 标签页 → 刷新页面
筛选出 XHR / Fetch 请求，重点关注协议/域名/端口与当前页面不同的请求（例如页面在 http://localhost:8080，却请求了 https://api.example.com/data）
点击该请求 → 查看 Response Headers → 找 Access-Control-Allow-Origin 字段值
若值为 * 且响应中同时存在 Access-Control-Allow-Credentials: true，或值直接回显了你可控的 Origin（如请求头带 Origin: https://evil.com，响应头返回 Access-Control-Allow-Origin: https://evil.com），即存在风险

很多静态页面通过 fetch() 或 XMLHttpRequest 发起请求，但前端代码不控制 Origin —— 这个头由浏览器自动添加。能否利用，取决于服务端是否校验它。

用 curl 或 Burp Repeater 手动发请求，重点测试服务端对 Origin 的处理逻辑：

Markdown to HTML

{"answer":"将 Markdown 转换为内嵌 CSS、样式精美的独立 HTML。完美适用于新闻简报、文档、报告及邮件模板。"}

下载

发送请求时显式带上 -H "Origin: https://attacker.com"
观察响应中 Access-Control-Allow-Origin 是否也变成 https://attacker.com（即反射）
再试 Origin: null、Origin: file://、Origin: https://x.com%00.example.com（部分旧服务会截断解析）
如果响应头原样反射且未校验白名单，配合前端带凭证（credentials: 'include'）就能读取敏感响应

以下标签加载资源时，**不触发 CORS 预检，也不受 Access-Control-Allow-Origin 限制**，即使响应头里写了也没用：

这些标签能加载成功，不代表后端有 CORS 漏洞；它们本就不走 CORS 流程。真正要盯的是 fetch()、XMLHttpRequest、new WebSocket() 这类脚本发起的请求。

双击打开的 HTML 文件运行在 file:// 协议下，此时浏览器会将 Origin 设为 null。不少开发环境或内部工具接口会错误地允许 Origin: null，导致本地 HTML 可直接读取内网 API 数据。

用 Chrome 打开本地 HTML（地址栏显示 file:///path/to/page.html）
在控制台执行 fetch("https://intranet/api/status", { credentials: "include" })
若成功返回且响应头含 Access-Control-Allow-Origin: null 或 Access-Control-Allow-Origin: * + Access-Control-Allow-Credentials: true，即存在可利用路径
这种配置在测试环境很常见，但极易被钓鱼 HTML 利用

真实漏洞往往藏在“谁都没配 CORS，但后端又没校验 Origin”的接口里，而不是前端 HTML 写错了什么。盯着响应头看，比翻源码更直接有效。