HTML本身无漏洞，问题源于不当拼接、渲染或解析引发XSS等攻击；innerHTML因直接解析执行字符串成XSS高发区；document.write()会覆盖文档流且易被劫持；CSP需精确配置，严格起步并结合上下文转义才有效。
HTML 本身不执行逻辑，所以不存在“HTML 漏洞”这种独立类型；真正出问题的，是 HTML 被不当拼接、渲染或解析时引发的 XSS、模板注入、开放重定向等实际攻击面。
为什么 innerHTML 是 XSS 高发区
浏览器会把字符串当作 HTML 解析并执行，一旦用户输入（比如评论、搜索词、URL 参数）未经处理就塞进 innerHTML，恶意脚本就直接运行了。
常见错误现象：
- 用户提交
<img src="1" onerror="alert(1)" alt="小白必看的HTML漏洞检测与防范实用手册" >，页面弹窗 - 后台返回 JSON 数据含 HTML 片段，前端用
el.innerHTML = data.html渲染后触发脚本
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先用
textContent替代innerHTML，除非你明确需要渲染 HTML - 必须渲染 HTML 时，用成熟库如
DOMPurify.sanitize()过滤，别自己写正则 - 服务端返回的 HTML 内容，也应做上下文感知的转义（如在属性中输出，要对双引号、
&等编码）
document.write() 在现代页面里基本等于自爆开关
它会覆盖整个文档流，且在页面加载完成后调用直接报错或清空页面。更危险的是，它常被用于动态加载第三方脚本，而这些脚本可能已被劫持或注入。
使用场景极少：仅限极早期静态页或某些老式广告 SDK 的 hack 写法。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 彻底禁用
document.write()：Chrome 已在 defer/script-type=module 下默认禁用，可配合 CSPscript-src 'unsafe-inline'外加block-all-mixed-content提前拦截 - 用
document.createElement()+appendChild()替代动态插入逻辑 - 检查构建产物（如 webpack 打包后的 JS）是否意外引入了含
document.write()的依赖
CSP 是 HTML 安全的最后一道防线，但配置错等于没设
CSP 不是开个头就完事的策略，它依赖精确的指令组合。一个宽松的 default-src 'self' 可能被 script-src 'unsafe-inline' 直接绕过。
典型错误配置：
- 只加了
script-src 'self'，却忘了style-src或img-src，导致 CSS 注入或数据外泄 - 用了
'unsafe-eval'放行eval()、setTimeout(string)，给 XSS 提供执行环境 - 未启用
report-uri或report-to，出问题完全无日志
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 从严格模式起步：
default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline' - 逐步放开，每放开一项都验证是否真有必要（比如
'unsafe-inline'往往可用nonce替代） - 上线前用
Content-Security-Policy-Report-Only头试跑一周，收集违规报告再调整
真正难的不是写对一行 CSP，而是搞清每个资源加载路径、每个第三方 SDK 的行为边界、以及你自己的模板引擎是否在服务端做了上下文敏感转义——这些细节漏掉一个，前面所有防护都可能失效。
