Yii框架的XSS防护不是开个开关就完事，核心在于“输入校验 + 输出转义 + 富文本白名单过滤”三层动作缺一不可；漏掉任意一层，比如只做Html::encode()却放行富文本、或只过滤输入却不处理输出，都可能被绕过。
Html::encode() 什么时候够用，什么时候不够用
纯文本场景下（如用户名、标题、地址），Html::encode($userInput) 是最轻量也最安全的选择：它把 变成 <code><，script 标签直接失效，连解析机会都不给。
但它在以下情况会出问题：
- 你允许用户提交带格式的内容（比如商品详情页的编辑器输出），
Html::encode()会把所有<p></p>、<strong></strong>全部转义成乱码，页面无法渲染 - 你把用户输入拼进 JavaScript 字符串里，例如
var desc = "= Html::encode($desc) ?>";—— 这种写法仍可能因引号闭合失败导致 XSS - 你在 JS 中用
innerHTML或document.write()插入内容，Html::encode()对 DOM 层面的注入无效
HtmlPurifier 必须配白名单，不能只调用 process()
HtmlPurifier::process($html) 默认行为是保守过滤，但 Yii 不自带默认配置，直接调用等于裸奔——它不会自动禁掉 onerror、javascript:、data:text/html 等高危属性和协议。
必须显式配置白名单，例如在组件配置中：
['HTML.Allowed' => 'p,strong,em,u,ol,ul,li,a[href|title],img[src|alt]']
关键点：
-
a[href]要限制协议，推荐写成a[href|title|rel]并在后端校验href是否以http://或https://开头 - 禁止启用
HTML.SafeIframe，除非你真需要嵌第三方视频且已严格校验src域名白名单 - 别在列表页、搜索页等高频接口里每次调用
HtmlPurifier::process()，开销大；建议缓存净化结果，或用 Redis 存$key = 'purified_' . md5($rawHtml)
输出到 JS 变量或属性时的特殊处理
用户数据进 JS 环境比进 HTML 更危险，因为没标签边界，一个未闭合的引号就能逃逸。
正确做法不是靠 Html::encode()，而是：
- 用
json_encode($value, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP)包裹后再插入 JS 字符串，确保双引号、反斜杠、<、&全被转义 - 绝对避免
document.getElementById('x').innerHTML = '= $userHtml ?>';这类写法；改用textContent或先用HtmlPurifier净化再插入 - 如果必须动态生成 script 标签（如埋点），用 CSP 的
nonce或hash控制执行权限，而不是拼字符串
容易被忽略的三个盲区
很多项目在测试环境看不出问题，上线后被扫出 XSS，往往栽在这三处：
- URL 参数里的
redirect_url、next类跳转字段，后端取值后直接header("Location: $url")或前端window.location.href = url—— 必须校验是否为站内路径，禁止开放协议（如javascript:、data:） - Cookie 中的
user_name或avatar_url，被 JS 读取后直接插入 DOM —— 即使后端已转义，JS 层仍需二次处理 - 后台导出 Excel 或 CSV 时，把用户输入字段原样写入文件，再被 Excel 解析执行宏或公式 —— 这属于“XSS 衍生攻击”，得在导出前对字段做
str_replace(['=', '+', '-', '@'], '', $value)过滤
真正难防的不是 <script>，而是那些看起来“合法”的字符组合。只要数据流经用户可控输入 → 输出到浏览器上下文，就必须按上下文类型选对应防护手段，不能复用同一套逻辑。
