本文详解为何基于关键词过滤（如屏蔽、）无法真正防御XSS，指出其严重绕过风险，并推荐使用textContent这一简单、可靠、零配置的防御方案。
本文详解为何基于关键词过滤（如屏蔽`<script>`、`<`、`>`）无法真正防御xss，指出其严重绕过风险，并推荐使用`textcontent`这一简单、可靠、零配置的防御方案。</script>
你当前的JavaScript代码完全不安全，存在严重的XSS漏洞。虽然你试图通过字符串匹配过滤、<code>>和script等关键词来“阻止”恶意代码，但这种黑名单式过滤极易被绕过——它既不全面，也不符合HTML解析规范，反而会制造虚假的安全感。
❌ 为什么你的过滤逻辑是危险的？
你的检查逻辑存在多个根本性缺陷：
-
大小写绕过：你只用
toLowerCase()处理后检查，但 HTML 标签对大小写不敏感，而攻击者可使用<script></script>、<img src="javascript:alert(1)" alt="如何安全地在网页中显示URL参数内容以防止XSS攻击" >等方式绕过； -
编码绕过：URL 中可传入 HTML 实体（如
<img>）、十进制/十六进制字符实体（如<script></script>）、Unicode 编码（如\u003cscript\u003e），你的.includes()完全无法识别； -
标签拆分与混淆：例如
<scr>ipt>alert(1)</scr>—— 你.replace("script", "")后变成<scr>ipt>alert(1)</scr>，仍可能被浏览器解析为有效标签； -
事件属性绕过：即使没有
<script></script>，攻击者可注入<img src="x" onerror="alert(1)" alt="如何安全地在网页中显示URL参数内容以防止XSS攻击" >或<div onclick="fetch('/api/steal?cookie='+document.cookie)">，而你的过滤未覆盖 <code>onerror、onclick等危险属性； -
双重解码/多层嵌套：现代浏览器支持多层解码（如
%253Cscript%253E→%3Cscript%3E→<script></script>），静态字符串检测毫无意义。
简言之：任何基于字符串关键词的前端过滤，都无法替代语义级的内容渲染隔离。
✅ 正确解法：永远使用 textContent，而非 innerHTML
最安全、最简洁、最符合Web标准的做法，是彻底避免将用户输入解析为HTML。只要你不把数据当作HTML插入，XSS就不可能发生。
<!-- 假设页面中有这两个元素 --> <span id="txt-code"></span> <div id="desc-area"> <p id="txt-desc"></p> </div>
<script>
const urlParams = new URLSearchParams(window.location.search);
// ✅ 安全：纯文本赋值，浏览器自动转义所有HTML特殊字符
document.getElementById("txt-code").textContent = urlParams.get('code') ?? "";
document.getElementById("txt-desc").textContent = urlParams.get('desc') ?? "";
</script>textContent 会将任意字符串（包括 <script>alert(1)</script>）作为纯文本插入DOM，浏览器自动将其显示为字面量，不会执行、不会解析、不会渲染为标签。这是由浏览器原生保障的安全机制，无需正则、无需黑名单、无需手动转义。
⚠️ 补充注意事项
-
不要混用：切勿在同一个元素上先设
textContent再改innerHTML，或反之；保持语义一致。 -
服务端仍需防护：前端
textContent是最后一道防线，但关键参数（如错误码、描述）应在服务端做白名单校验与长度限制，并避免将敏感上下文直接回显。 - 若真需渲染HTML（极少数场景）：必须使用经严格审计的HTML净化库（如 DOMPurify），并配置最小化白名单策略，绝不可自行实现过滤逻辑。
-
启用CSP（Content Security Policy）：作为纵深防御补充，在HTTP响应头中添加
Content-Security-Policy: default-src 'self'; script-src 'self'，可进一步限制内联脚本执行。
✅ 总结
| 方式 | 安全性 | 维护成本 | 推荐度 |
|---|---|---|---|
innerHTML + 关键词过滤 |
❌ 极不安全，易绕过 | 高（需持续更新规则） | ⛔ 禁止使用 |
手动HTML实体转义（如 & → &） |
✅ 安全（但易出错） | 中（需覆盖全部5个实体） | ⚠️ 不推荐，有更好方案 |
textContent（推荐） |
✅ 100% 安全，浏览器级保障 | 零成本，一行代码 | ✅ 强烈推荐 |
一句话牢记：想显示用户输入？用 textContent；想执行HTML？先问自己是否真的需要——99%的情况，你不需要。
