答案：不安全外部引用漏洞最典型路径是script/link/iframe/img的src或href属性动态拼接用户可控输入，如location.search、hash等，且未校验协议与域名。需重点检查拼接逻辑、白名单有效性及多层解码拼接场景。
直接看 script、link、iframe 和 img 标签的 src 或 href 属性是否动态拼接了用户可控输入，尤其是来自 location.search、location.hash、document.referrer 或 localStorage 的值——这是不安全外部引用漏洞最典型的触发路径。
检查 script/link 标签的 src/href 是否拼接 URL 参数
很多前端会用 JS 动态加载资源，比如根据 URL 参数决定加载哪个 CDN 版本或语言包。一旦没过滤，攻击者就能注入恶意域名：
- 常见危险写法：
const url = 'https://cdn.example.com/' + new URLSearchParams(location.search).get('lib');→ 然后赋给script.src - 更隐蔽的：从
document.currentScript的src中提取路径再拼接，若该 script 本身是通过 URL 注入的（如<script src="?a=evil.com/x.js"></script>），就可能被二次利用 - 注意大小写绕过：
javascript:、JAVASCRIPT:、data:text/html;base64,...都可能被当作合法协议传入
排查 iframe 和 img 的 src 是否接受用户输入
iframe 和 img 的 src 若直接受控，可导致钓鱼、CSP 绕过、甚至配合浏览器解析漏洞触发 RCE（虽极少见但历史上存在）：
- 典型风险点：
iframe.src = getQueryParam('embed');，且未校验协议和域名 - 容易被忽略的场景：用
img加载监控埋点时，URL 拼接了location.hostname或document.title，若标题含恶意 payload（如<img onerror="alert(1)">）且未编码就插入 URL，可能触发 XSS - Chrome 对
javascript:在iframe src中已禁用，但 Safari、旧版 Edge 仍可能执行；data:和blob:协议在部分上下文中仍可绕过 CSP
识别通过 eval / setTimeout 动态构造外部引用的脚本
这类写法不会出现在 HTML 源码中，但运行时会生成不安全引用，必须结合调试器追踪：
- 搜索 JS 中的
eval(、setTimeout(、setInterval(、Function(，看参数是否包含location或localStorage的值 - 例如：
setTimeout('loadScript("' + location.hash.substr(1) + '")', 0)——location.hash可控，且未做任何校验 - 注意 base64 解码后拼接：
atob(getQueryParam('cfg'))返回字符串再被eval，等于把解码权交给了攻击者
验证白名单逻辑是否真正生效
很多代码看似做了校验，实则形同虚设：
- 只检查开头：
url.startsWith('https://trusted.com')→ 攻击者用https://trusted.com.evil.com绕过 - 正则错误：
/^https?:\/\/(a\.b\.c|d\.e\.f)\//缺少末尾$，导致https://a.b.c.evil.com匹配成功 - 忽略端口和路径：
https://trusted.com:65535/xxx?redirect=javascript:alert(1)可能逃过简单域名比对 - 最关键一点：白名单应在校验后**立即使用 canonicalized URL**（即解析并标准化后的 URL），而不是对原始字符串做简单匹配
真正难发现的不是明文写死的 http:// 引用，而是那些藏在 JS 逻辑深处、经过多层 decode、拼接、缓存后再使用的动态引用——它们往往只在特定用户行为路径下才触发，必须靠断点+重放+修改响应三者结合才能揪出来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
