识别img标签src漏洞的本质是用户可控输入被直接拼入src属性且未校验协议与域名，如<img src="<%= userAvatar %>">中userAvatar为javascript:或data:恶意载荷。
HTML 标签漏洞不是语法错误，而是语义失控或上下文误用导致的安全风险。直接看 DOM 结构和属性值来源，比检查闭合更关键。
如何识别 img 标签的 src 漏洞
问题本质是：用户可控输入被直接拼进 src 属性，且未校验协议与域名。
- 常见错误现象：
<img src="<%= userAvatar %>">中userAvatar来自 URL 参数或数据库，值为javascript:alert(1)或data:text/html,<script>fetch('/steal')</script> - 排查方法：在浏览器开发者工具 Elements 面板中搜索所有
<img src=，重点看引号内是否含变量、模板占位符（如{{ }}、<%= %>）或 JS 动态赋值（如el.src = url） - 安全边界：只允许
http://、https://协议；域名必须在白名单内（如仅限cdn.example.com）；禁止javascript:、data:、file: - 修复建议：服务端做协议/域名校验 + 前端渲染前 HTML 编码（如 JS 中用
encodeURIComponent()处理路径段，但注意不能替代服务端校验）
meta http-equiv="refresh" 的跳转风险在哪
这个标签一旦被注入恶意 URL，会无提示自动跳转，钓鱼成功率极高。
- 典型危险写法：
<meta http-equiv="refresh" content="0; url=<%= request.getParameter("next") %>">——next参数未过滤就输出 - 为什么危险：浏览器不校验
content中的 URL，且跳转发生在 DOM 加载早期，用户几乎无法干预 - 排查要点：全局搜索
http-equiv="refresh"，检查其content属性值是否含任何用户输入源（URL 参数、Cookie、Header、表单字段） - 替代方案：优先用服务端 302 跳转；若必须前端跳转，用 JS 实现并加白名单校验（如
if (url.startsWith('/')) window.location = url）
为什么 form action 和 a href 也要查
它们本身不执行代码，但构成重定向链路的关键一环，常被忽略。
立即学习“前端免费学习笔记（深入）”；
- 容易踩的坑：
<form action="<%= targetUrl %>">或<a href="<%= link %>">中的变量来自用户提交，且未限制协议或域名 - 危害场景：攻击者构造链接
https://site.com/page?link=//evil.com/phish，用户点击后跳转到钓鱼页；或通过表单提交把敏感数据发往外部地址 - 兼容性影响：现代浏览器对
target="_blank"强制要求rel="noopener noreferrer"，否则新页面可通过window.opener控制原页面 —— 这虽非标签漏洞，但属关联风险 - 实操建议：对所有动态
action/href值，统一走一个校验函数（如isValidRedirect(url)），拒绝非白名单域名和非 HTTP(S) 协议
DOM XSS 常藏在哪些标签组合里
漏洞不在单个标签，而在“可执行上下文”与“用户输入”的意外交汇。
- 高危组合：
<div onclick="doSomething('<%= userInput %>')">、<img onerror="console.log('<%= data %>')">、<svg onload="alert(1)"> - 为什么难发现：这些标签本身合法，但事件处理器中拼接用户输入，等价于
eval()；浏览器不会报错，只有触发时才执行 - 排查技巧：搜索所有带内联事件的标签（
onclick、onerror、onload、onmouseover等），再逐个确认其值是否来自不可信源 - 根本解法：禁用内联事件，改用
addEventListener；所有用户输入渲染到页面前，必须经 HTML 实体编码（如<→）
真正难防的不是标签写错，而是把用户输入当成“内容”处理，却把它塞进了“代码”上下文。每次看到变量插进属性值或事件处理器里，都要停下来问一句：它会不会被当 JS 执行？
