字符串转义是防御XSS最基础的前端防护手段,需按HTML上下文(文本、属性、JS字符串、URL)采用对应转义策略,优先使用安全API如textContent,并配合CSP等纵深防御措施。

字符串转义是防御XSS(跨站脚本)攻击最基础、最关键的前端防护手段之一。核心原则是:**在将不可信数据插入HTML上下文前,必须根据具体插入位置进行对应类型的转义,不能一概而用HTML实体编码**。
明确数据插入的HTML上下文
同一段字符串,在不同位置插入,需采用不同的转义策略:
-
插入到HTML文本内容中(如
<div>xxx</div>)→ 使用HTML实体编码(如&→&,<→) -
插入到HTML属性值中(如
<input value="xxx">)→ 先做HTML实体编码,再确保引号("或')也被转义;若属性未加引号,风险极高,应避免 -
插入到JavaScript字符串中(如
<script>var x = "xxx";</script>)→ 必须使用JavaScript字符串转义(如"→",→\,换行符 →),仅HTML编码无效 -
插入到URL参数中(如
<a href="x.php?name=xxx">)→ 应使用encodeURIComponent()编码,而非encodeURI()或 HTML 转义
优先使用安全的API,避免手动拼接
直接操作 innerHTML、document.write 或模板字符串拼接用户数据极易出错。推荐方式:
- 用
textContent替代innerHTML渲染纯文本(自动规避HTML解析) - 动态创建元素时,用
setAttribute()设置属性,并确保值已按上下文转义 - 服务端渲染或使用现代框架(React/Vue/Svelte)时,依赖其默认的转义机制(如 React 的 JSX 表达式默认转义),但注意
dangerouslySetInnerHTML/v-html等“绕过转义”API 必须严格审查 - 若必须服务端输出JS上下文内容,建议将数据注入为JSON对象,用
JSON.stringify()(它会正确处理引号、反斜杠和控制字符)
不信任任何客户端输入,包括“看起来安全”的数据
以下情况仍需转义:
立即学习“Java免费学习笔记(深入)”;
- URL参数、表单字段、localStorage读取的内容、postMessage接收的数据
- 即使前端做了格式校验(如只允许数字/邮箱),服务端返回的数据也可能被篡改或缓存污染
- 后端API返回的“富文本”内容,若需渲染,应由后端做白名单过滤(如仅允许
<b><p>),前端不做信任性解码
补充建议:防御纵深与常见误区
单一转义不能替代整体防护策略:
- 始终设置
Content-Security-Policy响应头(如default-src 'self'),限制内联脚本和eval执行 - 避免使用
eval()、Function()、setTimeout(string)、setInterval(string)等动态执行字符串的API - 不要依赖正则替换“关键词”(如删掉
<script>)来防XSS——绕过方式极多,且破坏正常内容 - 对用户可控的重定向URL(如
redirect_url参数),应校验是否为白名单域名,不能只靠编码










