反射型xss的核心漏洞点是服务端将用户输入（如url参数、post数据）未经转义直接拼入html响应；必须根据输出上下文对、&、"、'等字符做精准转义，或使用dompurify等经验证的安全库。
反射型 XSS 的核心漏洞点，是服务端把用户输入（比如 URL 参数、POST body）未经转义就直接拼进 HTML 响应里。只要在输出前对这 5 个字符做严格转义：、<code>>、&、"、'，就能拦住绝大多数反射型攻击。
哪些地方必须转义？看输出上下文
不是所有地方都用同一套规则。关键看用户数据最终插在哪种 HTML 上下文中：
- 插入到 HTML 标签体中（比如
<div>{userInput}</div>）：必须转义、<code>>、&；"和'在这里不危险，但统一处理更稳妥 - 插入到双引号属性值中（比如
<input value="{userInput}">）：必须转义"和&；、<code>>、'不会提前闭合属性，但保留转义无害 - 插入到单引号属性值中（比如
<div data-id="{userInput}">）：必须转义 <code>'和& - 插入到 URL 属性（如
href、src）：不能只靠 HTML 转义，得先用encodeURIComponent()编码，再放进引号里 - PHP：用
htmlspecialchars($input, ENT_QUOTES, 'UTF-8')，ENT_QUOTES确保单双引号都被处理 - Java（JSP/JSTL）：用
<out value="${param.q}"></out>或 EL 表达式自带的${fn:escapeXml(param.q)} - Python（Jinja2）：默认
{{ value }}就是 HTML 转义的；如果关了 autoescape，必须显式写{{ value|e }} - Node.js（EJS）：用
（带等号）自动转义；不转义，慎用 - 纯文本展示：一律用
element.textContent = userInput - 必须渲染富文本（比如评论含链接、加粗）：先过
DOMPurify.sanitize(userHtml)，它默认剥离on*事件和javascript:协议 - React/Vue/Angular 等框架：它们的插值语法（如
{userInput}）默认转义，但像 React 的dangerouslySetInnerHTML或 Vue 的v-html是例外，用之前必须确认内容已由后端或 DOMPurify 处理过 -
<img src="1" onerror="alert(1)">—— 不含<script></script>，但能执行 JS -
@#@#@#@#@#@#@#@#@#@0——javascript:协议触发 - Unicode 变体、注释混淆、大小写混用（
<script></script>）都能绕过简单正则
服务端模板里怎么写才安全？
别手动拼字符串，用框架或语言内置的自动转义机制：
错误示范：res.send('<h2>Search result for ' + req.query.q + '</h2>') —— 这等于把 <script></script> 直接送进浏览器。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
前端 JS 动态渲染时为什么不能用 innerHTML？
哪怕你服务端已转义，前端再用 element.innerHTML = userInput，就等于重开一扇门。浏览器会重新解析那段字符串，转义实体又还原成原始字符，<script></script> 就复活了。
为什么正则替换 <script></script> 没用？
反射型 XSS 的绕过方式太多，比如：
真正可靠的防线只有两个：服务端输出时按上下文做标准 HTML 转义，或者用 DOMPurify 这类经过大量 XSS 测试验证的库。自己写的“过滤器”基本等于摆设。
