ThinkPHP框架XSS漏洞本质是开发者未对用户输入输出编码，修复需坚持“在哪输出就在哪转义、谁控制内容谁负责编码”原则，严格在模板、JS上下文、HTML属性、富文本等位置实施针对性转义与过滤。
ThinkPHP（TP）框架中XSS漏洞本质不是框架自带，而是开发者未对用户输入做输出编码或过滤就直接渲染到页面，导致恶意脚本在浏览器执行。修复核心是：**在哪输出、就在哪转义；谁控制内容，谁负责编码**。
TP中常见XSS触发位置
这些地方若直接使用用户数据且未处理，极易触发XSS：
-
模板中直接echo变量：如
{:input('get.id')}或{$data.content}未加转义修饰符 -
JS上下文中拼接用户数据：例如
var name = "{$user.name}";——引号内若含"或\可能逃逸 -
HTML属性值动态赋值：如
，当$id含双引号或>时破坏结构 -
富文本内容未过滤直接输出：后台允许用户提交HTML，前端又未用
htmlspecialchars或白名单过滤就echo
TP内置的XSS防护机制
ThinkPHP本身提供基础防护能力，但需主动启用：
-
模板自动转义（v5.1+默认开启）：使用
{$var}语法时，框架默认调用htmlspecialchars（ENT_QUOTES）；但{:xxx()}、{~xxx}等非变量标签不触发 -
显式转义函数：模板中可用
{|htmlspecialchars=$var}或{|htmlentities=$var}；控制器中可调用think\facade\View::assign()前手动处理 -
安全输出标签：v6.x支持
{:raw($var)}（绕过转义）和{:html($var)}（仅过滤script/style等危险标签），需按需选择
必须落地的修复操作
不能只依赖框架默认行为，以下为生产环境强制建议：
-
所有用户输入输出到HTML正文，统一用
{$var|htmlspecialchars=ENT_QUOTES,UTF-8}，避免依赖默认配置 -
输出到JS字符串时，必须双重处理：先JSON编码（
json_encode($str, JSON_UNESCAPED_UNICODE)），再放入单引号或双引号中，例如：var title = '{:json_encode($title)}'; -
富文本场景启用白名单过滤：使用
HtmlPurifier或TP扩展think-helper中的Security::cleanHtml()，禁用script、onerror、javascript:等高危标签和属性 -
设置HttpOnly + Secure Cookie：在
config/session.php中启用'http_only' => true和'secure' => true（HTTPS环境） -
添加CSP响应头：在中间件或全局配置中加入
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'");，逐步收紧至禁用unsafe-inline
验证是否修复到位
修复后务必手工验证典型攻击载荷是否被阻断：
- 输入
<script>alert(1)</script>→ 应显示为纯文本，不弹窗 - 输入
" onfocus=alert(1) autofocus=""→ 放入value="{$input}"中，不应触发事件 - 输入
javascript:alert(1)→ 作为链接href输出，应被转义为javascript:alert(1)而非可点击 - 检查浏览器开发者工具中Network标签页，确认响应头含
Content-Security-Policy且无报错
