关于使用json_encode抵御XSS攻击的合理性疑问

最近我们团队用安全扫描工具排查项目时，发现代码里有不少需要处理输入转义的区域，核心目标就是防范跨站脚本（XSS）攻击。扫描工具给出的建议是用htmlentities和json_encode来做输入清理，但我从一开始就不认可json_encode适合干这件事，查了一圈资料后更确定了——它从设计之初就不是为XSS防护场景打造的，能起到的防护效果纯属偶然的附带作用。

先明确json_encode的本职工作 #

json_encode的核心功能是把PHP里的数组、对象等数据结构转换成符合JSON规范的字符串。它处理字符的逻辑全围绕JSON语法正确性展开：比如转义双引号、反斜杠，处理不可打印字符等。从头到尾，它的设计目标里就没有“对抗XSS攻击”这一项。

依赖它做XSS防护的两大问题 #

• 场景局限性极强：只有当你把用户输入嵌入到JavaScript代码中，且用JSON格式包裹时，json_encode的转义可能刚好能防住部分XSS。但如果是输出到HTML内容、HTML属性、CSS等场景里，json_encode完全起不到应有的防护作用——它不会转义<、>、&这些HTML中的危险字符，攻击者随便就能注入恶意脚本。
• 防护效果不可靠：就算是在JS场景里，若不给json_encode加上正确的参数（比如JSON_HEX_TAG、JSON_HEX_AMP等），它也可能漏掉一些能触发XSS的字符。而且这种依赖“附带效果”的防护，哪天JSON规范或函数实现调整，防护就直接失效了，稳定性极差。

正确的XSS防护思路 #

别想用一个工具覆盖所有场景，得根据输出环境选对应的转义方式：

• 输出到HTML内容/属性里：用htmlspecialchars()（务必带上正确的编码参数，比如ENT_QUOTES | ENT_HTML5）或者htmlentities()，这才是专门为HTML场景设计的转义工具；
• 输出到JavaScript里：可以用json_encode配合JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_QUOT | JSON_HEX_APOS这些参数，但这只是JS场景的补充方案，不能当成通用的输入清理手段；
• 记住输出时转义才是黄金原则：不要在输入阶段就修改原始数据，因为同一个数据可能会用到不同场景中，输入时的清理既破坏数据完整性，也覆盖不了所有输出场景的防护需求。

内容的提问来源于stack exchange，提问作者Allie Fitter