前端XSS防护必须按上下文精细化编码：重点拦截on*事件、javascript:/vbscript:协议、srcdoc/data/style中的执行入口；禁用innerHTML/insertAdjacentHTML；URL反射需防闭合绕过；CSP仅为兜底，不可替代输出编码。
前端 HTML 代码一旦允许用户输入参与渲染，就天然具备 XSS 风险；单纯靠“删掉 <script>”或“过滤 on 开头的属性”远远不够，必须结合上下文做精细化审查。
哪些 HTML 属性必须重点拦截
浏览器执行 JavaScript 的入口远不止 <script> 标签。真正高频、隐蔽、易被漏掉的是以下属性：
-
onerror、onclick、onload、onfocus等所有以on开头的事件处理器（包括低频的oncut、oncontextmenu） -
href值以javascript:或vbscript:开头（如href="javascript:alert(1)"） -
src、data、srcdoc中含javascript:协议（srcdoc尤其危险，等价于内联 iframe） -
style中含expression()（IE）、url(javascript:...)（部分 CSS 解析器）
注意：srcdoc 和 data 属性在审查中常被忽略，但它们直接触发 HTML 解析，和 innerHTML 同级风险。
innerHTML / insertAdjacentHTML 是高危信号，不是可选项
只要代码里出现 element.innerHTML = userInput 或 element.insertAdjacentHTML('beforeend', userInput)，就等于主动放弃转义，必须立刻干预。
立即学习“前端免费学习笔记（深入）”；
- 这类写法绕过框架默认防护（如 React 的
{userInput}自动转义），也不受 CSP 的 script-src 限制 - 即使后端已做过滤，前端再拼一次 DOM，就可能二次引入未编码内容
- 替代方案优先用
textContent；若真需渲染 HTML，必须由服务端返回已净化的 HTML 字符串，并明确标注来源可信
常见误判：用 document.write() 拼接用户输入，本质和 innerHTML 无异，且无法被现代 CSP 拦截。
URL 参数反射到属性时的闭合绕过极难察觉
看似安全的回显逻辑，比如把 location.search 的 q=xxx 直接填进 <input value="xxx">，其实极易被注入。
- 攻击 payload：
" onfocus="alert(1)→ 渲染为<input value="" onfocus="alert(1)"> - 绕过手段包括用
"替代英文双引号、用onblur等冷门事件、甚至利用属性值未加引号时的空格截断（<a href=javascript:alert(1)>） - 审查时不能只看是否“有引号”，而要看整个属性值是否被完整包裹、是否做了上下文敏感编码（如 HTML 属性内需编码双引号、单引号、等号、尖括号）
DOM 型 XSS 最容易被漏掉的地方，恰恰是这些不经过后端、纯前端解析 URL 或 localStorage 数据并直接塞进 DOM 的位置。
CSP 不是补丁，而是兜底策略
Content-Security-Policy 头不能替代输出编码，但它能大幅降低 XSS 成功后的危害。
- 设置
script-src 'self'可阻止内联脚本和外部未授权脚本执行，但对onerror这类内联事件无效（需配合'unsafe-inline'才生效，反而削弱防护） - 更有效的组合是：
script-src 'self'; object-src 'none'; base-uri 'self';，并禁用eval类函数 - 前端动态生成的 CSP（如通过
<meta http-equiv="Content-Security-Policy">）不可靠，应由后端响应头统一设置
真正关键的防线始终在数据落地前：所有用户输入，在进入任何 HTML 上下文之前，都必须按该上下文做对应编码——属性值、文本节点、JS 字符串、CSS 内联样式，编码规则全不同。漏掉一种上下文，就等于留了一扇没锁的门。
