HTML代码本身不执行逻辑，但作为XSS等漏洞的“发射台”，排查重点是数据来源、流向及渲染方式；需紧盯innerHTML赋值、模板字符串拼接、属性值动态填充三类高危位置，并结合开发者工具手动注入测试与服务端上下文敏感转义。
HTML代码本身不会执行逻辑，但它是XSS、SSRF、信息泄露等漏洞的“发射台”——排查重点从来不是语法对错，而是数据从哪来、怎么流、最终怎么渲染。
怎么快速定位用户输入是否被直接插入HTML
所有XSS风险都始于“未转义的动态内容”。重点盯住三类位置：
-
innerHTML赋值（尤其在document.getElementById(...).innerHTML = userInput这类写法） - 模板字符串拼接：
<div>${userInput}</div>，且未经过框架自动转义（如原生JS或老旧模板引擎） - 属性值动态填充：
<img src="${url}">或<a href="${link}">，其中url/link来自URL参数、表单提交或API响应
浏览器开发者工具的 Elements 面板里右键“Edit as HTML”，手动注入 <img src=x onerror=alert(1)> 测试是否执行；若弹窗，说明该处未转义。
为什么W3C验证器查不出XSS漏洞
W3C Markup Validation Service 只检查语法合规性（比如标签是否闭合、alt 是否缺失），它完全不关心你把 userInput 直接塞进 src 或 onerror ——这些在HTML语法上完全合法。
立即学习“前端免费学习笔记（深入）”；
真正要查的是语义和上下文：
-
javascript:、data:协议出现在src/href中，属于高危信号 -
onerror、onclick等事件属性值里包含未编码的 JS 逻辑 -
base标签被用户控制，会导致整个页面相对路径被劫持
这类问题必须靠人工代码审查 + 关键字搜索：grep -r "innerHTML\|\.src=.\+[^[:space:]]\|onerror" src/。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
修复时别只依赖前端转义
客户端转义（如 textContent 替代 innerHTML）能防一部分XSS，但无法替代服务端防护。原因很实际：
- 攻击者可禁用JS、绕过前端校验，直接向后端发恶意请求
- 同一个接口可能被多个前端调用（Web、App、第三方嵌入），前端转义无法覆盖全部场景
- 服务端输出到HTML时，若没做上下文敏感转义（比如在
script标签内插变量却只做了HTML实体编码），照样会出问题
正确做法是：服务端模板渲染时，根据插入位置选择转义方式——HTML 上下文用 htmlspecialchars()（PHP）、escapeHtml4()（Java）；JavaScript 字符串内插用 JSON 编码；URL 参数用 encodeURIComponent()。
CSP不是补丁，是必须配置的底线
即使所有输出都转义了，CSP 仍是防止XSS的最后一道闸门。仅靠它不能代替转义，但没它，一次漏转就是沦陷。
最小可行配置示例（放在 <head> 中）：
Content-Security-Policy: default-src 'self'; img-src 'self' https:; script-src 'self' 'unsafe-inline' 'unsafe-eval';
注意两点：
-
img-src必须显式限制，否则<img src="javascript:...">仍可触发 XSS（现代浏览器已拦截，但旧版或配置宽松时仍有效） -
'unsafe-inline'和'unsafe-eval'是危险项，上线前应通过哈希或nonce机制移除
最易被忽略的点：CSP策略需由服务器HTTP响应头发送（Content-Security-Policy），而非仅靠 <meta http-equiv="Content-Security-Policy"> ——后者在部分情况下不生效，比如含 script-src 时。
