ThinkPHP模板变量默认不转义，XSS高发，需按输出上下文显式转义：HTML内容用htmlspecialchars，属性值用htmlentities(ENT_QUOTES)，JS用json_encode，富文本须用HTMLPurifier过滤，禁用default_filter。

模板输出时默认不转义，必须手动处理

ThinkPHP 的 assign() 和模板变量输出（如 {$name}）默认不做 HTML 转义，这是 XSS 高发点。框架没替你兜底，得自己决定哪里该转、怎么转。

常见错误现象：{$user_input} 直接渲染用户提交的带 <script> 的内容，浏览器执行脚本；或富文本编辑器内容被双重转义（显示为

）。

• 纯文本展示用 {:htmlspecialchars($var, ENT_QUOTES, 'UTF-8')}，最稳妥
• 模板中简写语法 {$var|htmlspecialchars} 也行，但注意：它不加 ENT_QUOTES 参数，默认不转义单引号，攻击者可用 onerror="alert(1)" 绕过
• 富文本场景（如后台文章编辑）不能全局转义，应配合白名单过滤（如使用 htmlpurifier），而非依赖 htmlspecialchars

控制器层提前过滤不如模板层按需转义

有人习惯在 Controller 里对所有输入调用 htmlspecialchars() 再传给模板，这反而容易出问题——同一变量可能既用于 HTML 输出，又用于 JS 字符串或属性值，统一转义会破坏数据原始性。

使用场景差异明显：title 渲染在 <h1> 里要转义，但作为 <meta name="description"> 的 content 属性值，还需额外处理双引号和换行；若后续要 JSON 输出到前端 JS，又得还原。

立即学习“PHP免费学习笔记（深入）”；

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

• 推荐做法：只在模板输出点做上下文敏感的转义，比如属性值用 {:$var|htmlentities=ENT_QUOTES}，JS 字符串内嵌用 {:json_encode($var)}
• 避免在 assign() 前对变量做任何转义，保持数据“干净”
• input() 获取的数据默认未过滤，不要误以为框架已帮你 sanitize

内置 html_entity_decode 和 htmlspecialchars_decode 不是防御手段

这两个函数常被误用作“反向清理”，比如想把用户存的富文本恢复后直接输出。但它们只是解码，并不校验标签合法性，<img src=x onerror=alert(1)> 解码后照样执行。

性能影响不大，但逻辑上完全走反了：XSS 防御核心是“输出时编码”，不是“存储时解码”。存什么就存什么，展示时再按位置决定怎么编码。

• 数据库里存原始 HTML 是 OK 的，只要读出来后不裸输出
• html_entity_decode() 在 ThinkPHP 模板里基本没正当用途，除非你明确知道上游已全量转义且现在要还原成可编辑状态
• 真需要处理富文本，请用独立库（如 HTMLPurifier），别靠 PHP 内置函数拼凑过滤规则

开启 default_filter 配置有隐藏风险

ThinkPHP 允许在配置中设置 'default_filter' => 'htmlspecialchars'，看起来一劳永逸，但实际会覆盖所有模板变量，包括那些本不该转义的场景——比如 url 变量含 &，转义后变成 &，链接直接失效。

兼容性差：升级 ThinkPHP 版本时，这个配置可能被新版本忽略或行为变更；团队协作时，别人很难意识到某处异常是全局 filter 导致的。

• 禁用 default_filter，改用显式转义，哪怕多打几个字
• 如果项目历史包袱重，至少把 default_filter 改成空数组，再逐个页面补 |htmlspecialchars
• 检查日志中是否出现 htmlspecialchars(): Invalid multibyte sequence 错误——说明传入了非法 UTF-8 字节，这时 htmlspecialchars 会返回空字符串，页面丢内容

事情说清了就结束。真正难的不是加那几个函数，而是每次输出前都得问一句：这个变量最终出现在 HTML 的哪个位置？标签内？属性里？JS 字符串？还是 URL 参数？漏掉一个上下文，就等于留了一扇没锁的门。