Yii框架XSS防护需按上下文精准选型：纯文本用Html::encode()编码特殊字符，富文本必须用HtmlPurifier白名单过滤；filter验证器不防XSS，防护关键在输出层而非输入层。
Yii框架对XSS的防护不能只靠“开了就安全”——Html::encode() 适合纯文本，但一遇到富文本、商品描述、后台编辑器内容，它就会把 <p> 也转成乱码；而漏掉输出转义或误用 safe 规则，直接导致存储型 XSS。
Html::encode() 什么时候够用，什么时候会翻车
它只是把 <、>、"、'、& 做 HTML 实体编码，不碰标签结构，也不过滤属性。所以：
- 用户提交纯文本评论（如“好评！”），你用
Html::encode($comment)渲染，结果是显示文字<strong>好评！</strong>—— 安全但语义丢失 - 用户在富文本编辑器里写了
<p>支持 <strong>加粗</strong></p>，你照样Html::encode()，页面就变成一堆源码，不是排版 - 如果忘了调用它，比如直接
echo $model->content;，且内容含<script>alert(1)</script>，XSS 立刻触发
HtmlPurifier 是怎么解决富文本 XSS 的
它不是简单替换字符，而是解析 HTML 树，按白名单规则删掉危险节点和属性。默认配置已禁用 <script>、onerror、javascript:、data: 等所有已知 XSS 载体。
实际使用要显式调用：
use yii\helpers\HtmlPurifier; echo HtmlPurifier::process($htmlContent);
注意几个关键点：
- 必须安装
ezyang/htmlpurifierComposer 包，Yii 不自带运行时 - 首次调用会初始化配置并编译缓存，后续快很多；但别在每条商品列表项里都调，高频接口建议缓存净化结果
- 如需允许额外标签（比如
<video>或class属性），得自定义配置，不能只改allowedTags，还得放开对应属性白名单 - 它不处理 CSS 内联样式里的
expression()或url(javascript:...)，这些得靠额外规则或 CSP 头补位
为什么 rules() 里的 filter 验证器防不了 XSS
filter 验证器只做输入清洗，比如 trim、intval、strtolower，它不会删 <script>，也不会阻止用户存入带恶意属性的 <img> 标签。
典型错误写法：
['content', 'filter', 'filter' => 'strip_tags'], // 错！strip_tags 不过滤属性，且可能被绕过 ['content', 'safe'], // 更错！等于告诉框架“这字段我全权负责”，但你啥都没做
正确思路是：
- 输入层：用
string、required等验证器控长度和必填，不依赖filter拦 XSS - 存储层：原样存（除非业务强制要求预处理），因为不同场景需要不同净化策略
- 输出层：根据上下文选
Html::encode()（纯文本）或HtmlPurifier::process()（HTML 内容）
容易被忽略的三个执行时机
XSS 发生在输出渲染那一刻，但开发者常在三个地方漏掉防护：
- JS 变量注入：比如
<script>var desc = "= $model->content ?>";</script>—— 这里不能用Html::encode()，得用Json::encode()，否则引号和反斜杠会破坏 JS 结构 - HTML 属性值：比如
<div title="= $model->title ?>">—— 即使内容是纯文本，也要用Html::encode()，否则用户输" onclick="alert(1)就中招 - URL 参数拼接：比如
<a href="/user/= $id ?>/edit?from== $model->source ?>">——$model->source必须用urlencode()或Url::to()，不能裸插
真正难的不是“有没有方案”，而是每个输出点都要判断上下文类型，并匹配对应的编码方式——模板里混着 HTML、JS、URL、CSS，一个漏判，整个防护链就断了。
