HTML前端安全性必须聚焦XSS防护、内容隔离与敏感信息保护；用户输入动态插入DOM前须调用DOMPurify.sanitize()，默认移除script、iframe、on*属性及javascript:协议，后端须用jsoup或bleach二次净化并配置协议白名单，富文本必须渲染于sandbox iframe且配合CSP nonce策略。
HTML前端代码的安全性不能靠“看起来干净”或“W3C验证通过”来判断，真正有效的评估必须聚焦在三个可验证的层面：是否阻止XSS注入、是否隔离不可信内容、是否暴露敏感信息。其他所有检查——比如语义标签是否正确、doctype是否规范——都属于质量或合规范畴，不直接决定安全性。
检查所有用户输入是否经过DOMPurify.sanitize()处理
只要用户输入（评论、昵称、搜索词、富文本）被动态插入到DOM中，就必须调用DOMPurify.sanitize()，且不能跳过默认配置。它默认移除<script>、<iframe>、所有on*属性（如onclick）、javascript:伪协议，这是最轻量但最可靠的防线。
- 别自己写正则过滤——
/<script>/i之类极易被绕过，比如用<scr<script>ipt></script>或Unicode编码 - 别只在前端做——后端必须二次净化，用
jsoup（Java）或bleach（Python），并显式配置allowed_protocols=['https', 'http'] - 别把
DOMPurify.sanitize()结果直接塞进innerHTML——确保你用的是返回的字符串，而不是误传了原始输入
确认富文本渲染是否在sandbox iframe中隔离
哪怕用了DOMPurify.sanitize()，也不能把富文本内容直接插入主页面。浏览器新特性、0day漏洞或配置疏漏都可能导致净化失效。必须强制走沙箱隔离路径。
-
<iframe sandbox="allow-scripts allow-same-origin">是底线，但必须去掉allow-top-navigation和allow-popups -
src不能是about:blank或javascript:void(0)——要用blob:URL或独立子域（如preview.example.com），避免共享主站cookie和localStorage - 父子通信必须用
postMessage()，且接收端必须校验event.origin和event.source，否则沙箱形同虚设
验证CSP头是否禁用unsafe-inline并启用nonce
Content-Security-Policy不是摆设。只配default-src 'self'等于没配——它完全挡不住内联脚本、eval()或事件处理器里的JS。
立即学习“前端免费学习笔记（深入）”；
- 必须禁用
'unsafe-inline'和'unsafe-eval'，改用nonce机制：服务端生成随机值（如abc123），写入<script nonce="abc123">，并在响应头中声明script-src 'nonce-abc123' - 图片、字体等资源要单独放开，比如
img-src https: data:，否则CSP拦截会导致页面残缺，反而诱发开发者绕过策略 - 开发期必须开启
report-to或report-uri，收集CSP违规日志——不看报告，就等于闭眼防守
最容易被忽略的是“信任链断裂”：前端用DOMPurify.sanitize()，后端用jsoup，CSP也配了，但富文本却仍用innerHTML直接插入主文档；或者nonce值在服务端硬编码、复用多次。安全不是 checklist，而是每个环节都得咬合到位。
