HTML漏洞排查需聚焦用户输入点与动态渲染环节，重点检查img/script/iframe等标签的src属性是否直接拼接不可信数据，必须服务端校验+上下文敏感转义+CSP兜底。
HTML网页漏洞排查不是靠“扫一遍代码就完事”，而是得盯住几个关键输入点和渲染环节——尤其是那些把用户数据直接塞进<img alt="HTML网页漏洞排查与安全加固教程" >、<script></script>、<a></a>、<iframe></iframe>标签的地方。不加过滤地拼接 src、href、srcdoc 或 innerHTML，基本等于给 XSS、SSRF、恶意跳转开了后门。
怎么快速定位危险的 <img src="..." alt="HTML网页漏洞排查与安全加固教程" > 标签
真正出问题的不是静态图片，而是 src 值来自用户输入、URL 参数、数据库字段或 JS 变量的那些动态 <img alt="HTML网页漏洞排查与安全加固教程" > 标签。
- 在浏览器开发者工具里搜索
document.querySelectorAll('img[src]')，再逐个检查src属性是否包含javascript:、data:text/html、vbscript:或带双斜杠//后接不可信域名的 URL - 用正则全局搜代码：
src\s*=\s*[\'"]\s*(?!(https?:\/\/|\/))—— 匹配所有非绝对协议、非站内路径的 src 赋值（比如拼接了 user_input 的地方） - 特别注意 CMS 插件、评论系统、富文本编辑器输出（如
dangerouslySetInnerHTML）——这些地方常绕过前端校验，直接把未消毒内容写进 DOM
<script></script> 和 <iframe></iframe> 的 src 属性更危险，因为能直接执行
比起 <img alt="HTML网页漏洞排查与安全加固教程" >，<script src="..."></script> 和 <iframe src="..."></iframe> 的 src 一旦被污染，危害等级直线上升：前者可窃取 Cookie、伪造请求；后者可能加载钓鱼页面或触发父页面权限泄露。
- 禁止任何用户可控字符串直接赋值给
<script src="%24%7BuserInput%7D"></script>—— 这种写法必须砍掉，改用预定义白名单 ID 映射到 CDN 地址 -
<iframe src="..."></iframe>必须加sandbox属性（至少含allow-scripts和allow-same-origin的组合要谨慎），且 src 域名必须硬编码或走后端签名 URL - 用 CSP 的
script-src和frame-src指令做兜底，比如script-src 'self' https://cdn.example.com，拒绝所有内联脚本和未知域脚本
为什么只做前端校验根本防不住 XSS？
因为攻击者根本不会走你的表单提交流程。他们可以直接构造 URL、调用 API 接口、甚至用 curl 发送恶意 payload 到你后端，只要后端没校验，数据存进数据库，所有读取该字段的页面都会中招。
立即学习“前端免费学习笔记（深入）”；
- 服务端必须对所有入库/输出的 HTML 敏感属性（
src、href、onerror、onclick）做上下文敏感的转义：比如输出到 src 属性时，应 HTML-encode 引号和斜杠，而不是只过滤<script></script> - 不要信任 “前端 JS 过滤了” —— 浏览器禁用 JS 后，你的过滤逻辑就失效了；也不要依赖 “后端只允许 http/https” —— 攻击者可以先上传一个合法图片，再通过 SSRF 把它当跳板打内网
- 最稳妥的做法是：用户只传文件 ID 或标识符，由后端查表生成带签名的临时 URL（如
https://cdn.example.com/u/1234567890?sig=abc...），前端只负责渲染这个固定结构的链接
真正容易被忽略的，是那些看似“只是展示”的功能：头像预览、富文本中的图片插入、后台日志里的请求 URL 回显……它们都可能成为漏洞入口。安全不是加一层 filter 就万事大吉，而是从数据流入、存储、再到输出的每个环节，都明确知道“这段字符串最终会出现在哪个 HTML 上下文中”，然后按需消毒。
