xss修复关键在输出位置的编码与上下文处理：对innerhtml等危险api严格校验输入，富文本用dompurify，url参数和json插入需分别做协议白名单和json序列化转义，强制csp策略兜底。
直接看输出位置和数据流向，别在入口处瞎过滤——XSS漏洞本质是“不该执行的代码被浏览器执行了”，修复关键在哪里插入、怎么插入、插完谁来解析。
查 innerHTML、document.write 这类危险写法
这些函数会把字符串当作 HTML 解析并执行，只要参数含用户输入，基本等于开门迎客。
- 全局搜索项目中所有
innerHTML =、outerHTML =、document.write(、insertAdjacentHTML(调用 - 重点检查拼接逻辑：
el.innerHTML = '<div>' + userInput + '</div>'是高危写法；el.textContent = userInput是安全替代 - 注意框架封装层：Vue 的
v-html、React 的dangerouslySetInnerHTML本质也是innerHTML，同样要盯紧 - 如果必须渲染 HTML（如富文本），不要手写净化逻辑，用
DOMPurify.sanitize()处理后再塞进去
盯死 location.search、location.hash 这些前端数据源
DOM 型 XSS 不经过服务器，全靠前端自己把 URL 参数或本地存储内容往 DOM 里乱塞。
- 在浏览器控制台执行
location.search和location.hash，看是否被脚本读取并直接用于 DOM 操作 - 常见危险组合：
document.getElementById('x').src = location.hash.slice(1)、eval(decodeURIComponent(location.search.split('code=')[1])) - 不要用正则简单替换
javascript:—— 攻击者可用JaVaScRiPt:、%6A%61%76%61%73%63%72%69%70%74:绕过；应强制白名单协议，如只允许http://、https://、/ - JSON 插入到
<script></script>标签时，不能用 HTML 转义（会破坏引号），要用 JSON 序列化工具确保双引号、反斜杠等被正确转义
别信前端校验，但得管住输出编码
用户绕过表单限制、禁用 JS、直接发请求都是分分钟的事，前端验证只防君子；但输出编码是最后一道防线，必须做且必须做对。
- 纯文本展示一律用
textContent，别用innerHTML+ 手动 replace 替换、<code>>—— 容易漏掉这类编码绕过 - 属性值插入（如
input.value、a.href）需按上下文编码：HTML 属性用 HTML 实体编码，JS 字符串内用 JavaScript 字符串转义 - 服务端输出时，优先调用语言原生函数：
PHP用htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，Java用StringEscapeUtils.escapeHtml4() - 别在 JS 里写
escapeHTML工具函数去处理后端返回的数据——容易漏场景、难维护；让模板引擎或框架自动做（如 Nunjucks 的{{ var }}默认转义）
加 CSP 头不是万能，但能兜底关键执行路径
CSP 是浏览器层面的“熔断器”，不能代替编码，但能在编码漏掉时阻止恶意脚本运行。
- 至少启用
Content-Security-Policy: default-src 'self'; script-src 'self'，禁止内联脚本和外部脚本 - 禁用
eval类行为：加上script-src 'self' 'unsafe-eval'中的'unsafe-eval'必须删掉 - 避免使用
'unsafe-inline'—— 它会让<script>alert(1)</script>或onclick="alert(1)"直接生效 - 开发阶段用
Content-Security-Policy-Report-Only头收集违规报告，确认策略不影响正常功能后再切到强制模式
最容易被忽略的是 JSON 内嵌和 URL 协议校验：前者不走 HTML 编码流程，后者靠大小写/空格绕过太常见。这两处一松，前面所有转义都白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
