端到端加密场景下如何安全转义HTML字符？

现有方案的安全性评估 #

你当前的手动转义方案已经覆盖了绝大多数常见的HTML注入风险场景，但仍存在两处可被利用的疏漏：

1. 你的转义函数存在笔误：单引号转义的实体&#x27末尾缺少分号，正确写法应为'，这个疏漏会导致部分解析规则宽松的浏览器可以绕过转义注入恶意代码。
2. 手动维护转义规则的方案容错率极低：后续如果新增业务需求（比如支持消息中的链接、emoji解析），很容易出现规则遗漏，给XSS攻击留下空间。另外这种字符串拼接HTML的写法本身就属于风险范式，后续维护时只要有一处漏加转义调用，就会直接导致安全漏洞。

更安全的实现方案 #

优先选择框架/原生API内置的安全能力，不要手动维护转义规则：

• 如果你不需要消息支持任何富文本格式，直接使用DOM文本赋值接口即可，浏览器会自动完成所有特殊字符转义，完全不需要自己写转义逻辑，示例代码如下：

let decryptedData = decrypt(message, iv);
// jQuery的text()方法会自动转义所有HTML特殊字符，避免注入风险
$('<div class="message_user"></div>').text(decryptedData).appendTo(".messages_container");

• 如果需要支持有限的富文本格式（比如仅允许粗体、链接等少量格式），不要自己写正则过滤，直接使用经过社区长期验证的XSS过滤库处理解密后的内容，可覆盖几乎所有已知的注入绕过手段。
• 可选额外防护层：给消息渲染区域加上严格的内容安全策略（CSP）规则，禁止该区域内执行任何脚本、加载未知来源的外部资源，就算出现极端的注入场景，也能阻断恶意代码的执行。

内容的提问来源于stack exchange，提问作者Sergei Hronov