innerhtml赋值前必须转义，否则直接写element.innerhtml=userinput是前端xss最常见入口，哪怕用户只输入一个恶意脚本也会触发攻击。
innerHTML 赋值前必须转义，否则等于开后门
直接写 element.innerHTML = userInput 是前端 XSS 最常见的入口。哪怕用户只输入一个 或 <code>"，都可能被浏览器解析为标签或属性闭合点，进而触发 <img src="x" onerror="alert(1)"> 这类 payload。
实操建议：
- 纯文本场景一律改用
element.textContent = userInput——不解析 HTML，零风险 - 必须渲染富文本时，先过
DOMPurify.sanitize(dirtyHtml)，再赋给innerHTML；别自己写正则删<script></script> - 服务端返回的 JSON 字段若已含 HTML 实体（如
"<div>"），前端不能再二次转义，否则显示为字面量
HTML 属性值里插用户数据，光转义 不够
把用户输入塞进 title="{{ userInput }}" 或 data-id="{{ userInput }}" 时，攻击者能用引号提前闭合属性，再注入事件处理器，比如输入 " onclick="alert(1)，最终生成 title="" onclick="alert(1)"。
实操建议：
- 双引号包裹的属性（
title="xxx"）必须转义"→"；单引号包裹（title='xxx'）则转义'→' - URL 类属性（
href、src）不能只做 HTML 转义，得先encodeURIComponent()，再拼入带引号的属性值 - 绝对避免
<button onclick="doSomething('{{ userInput }}')"></button>这种写法——事件处理器内嵌用户数据，无解
JS 字符串上下文需要 JS 转义，不是 HTML 转义
在 <script>var name = "${userInput}";</script> 中，只对 、<code>& 做 HTML 实体转义完全无效。攻击者可输入 \u003cimg\u0020onerror=alert(1)\u003e，JS 引擎照样执行。
实操建议：
- 优先用
JSON.stringify()包裹用户数据：var name = ; - 若必须拼接字符串，确保使用 JS 字符串安全转义函数（如 Node.js 的
jsesc库），而非 HTML 转义函数 - 禁止用
eval()、new Function()、setTimeout(string)执行任何含用户输入的 JS 片段
自己写 escapeHTML 函数极易绕过
网上常见这种代码：str.replace(/&/g, '&').replace(/, '。它漏掉 Unicode 变体、注释干扰、大小写混淆等大量绕过方式，比如 <code><img> 或 <scr>ipt>alert(1)</scr> 都能逃逸。
实操建议：
- 前端不要自己实现转义逻辑；用
DOMPurify.sanitize()处理 HTML，用JSON.stringify()处理 JS 上下文 - 服务端转义必须用语言原生函数：PHP 用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，Java JSTL 用<out value="${userInput}"></out> - 模板引擎中确认是否默认转义：Jinja2 默认转，但
{{ userInput | safe }}会绕过；EJS 默认不转，必须手动
关键点在于：XSS 防护不是“加一层过滤”，而是按输出位置选择对应编码规则。同一个用户输入，在 HTML 文本、属性、JS 字符串、URL 四种上下文里，要分别走四套转义逻辑。漏掉任意一种，就等于留了一扇没锁的门。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
