Yii框架的安全组件并非简单的功能堆砌，而是一套内聚的防御体系。开发者拿到手的不只是几个类文件，而是一张已经织好的安全网。这张网的核心逻辑在于：将常见攻击的防御成本降到最低，让安全编码从“额外工作”变成“默认行为”。

认证与授权：不是一回事，但必须一起用

很多开发者容易混淆认证和授权，Yii通过两个独立组件把这件事说清楚了。认证组件yii\web\User负责回答“你是谁”，授权组件yii\rbac\ManagerInterface负责回答“你能干什么”。

User组件实际上是一个身份管理容器。它不强制你使用哪种认证方式，而是提供了一个统一接口。你可以用数据库表认证、LDAP认证，甚至对接第三方OAuth2服务。关键在于配置identityClass属性，指向实现了IdentityInterface接口的类。这个接口要求实现findIdentity、getId、validatePassword等方法。一旦配置完成，控制器里直接调用Yii::$app->user->identity就能拿到当前用户的所有信息，不需要重复写查询逻辑。

授权部分，Yii提供了完整的RBAC实现。数据表默认命名为auth_item、auth_item_child、auth_assignment和auth_rule。这套表结构设计得很精妙，auth_item同时存储角色和权限，通过type字段区分，这意味着权限本身也可以被继承和嵌套。业务上需要“部门经理”继承“普通员工”所有权限时，直接建一条child关系就行，不用重新分配。更关键的是auth_rule表，它允许你写动态规则。比如“只能修改自己创建的文章”这种需求，不是简单分配一个权限就能解决的，需要运行时判断。你只需实现execute方法，返回布尔值，RBAC管理器会自动调用。

请求过滤：输入安全的第一道闸门

Yii的请求处理流程里，安全过滤发生在控制器动作执行之前。这得益于框架的过滤器机制，尤其是内置的yii\filters\AccessControl和yii\filters\VerbFilter。

AccessControl是授权检查的入口。在每个控制器的behaviors方法里配置它，可以精确到动作级别。rules数组里定义allow、actions、roles等属性。这里的roles不限于RBAC角色名，可以是角色名、权限名，甚至是一个匿名函数。匿名函数接收当前用户对象，返回布尔值，这给复杂业务逻辑留了口子。比如“仅允许VIP用户且账户余额大于100”这种组合条件，用闭包一行代码就能解决。VerbFilter则限制HTTP请求方法，防止攻击者通过GET请求触发本该POST提交的敏感操作。这两个过滤器组合使用，能在控制器层面拦截大部分越权尝试。

更深层的输入过滤依赖yii\helpers\HtmlPurifier。这个辅助类是对HTML Purifier库的封装，专门处理用户提交的富文本内容。它不简单是strip_tags的替代品，而是基于白名单的HTML净化器。你可以定义哪些标签、哪些属性允许保留，其余全部剔除。配置项很细，比如允许a标签但强制添加rel="nofollow"，允许img标签但强制过滤onerror事件。实际使用时，建议在模型的rules里直接调用：

['content', 'filter', 'filter' => function($value) {
    return HtmlPurifier::process($value, [
        'HTML.Allowed' => 'p,ul,li,a[href],img[src]',
        'HTML.Nofollow' => true,
    ]);
}],

这样数据在存入数据库前就已经被清洗，前端输出时不用再担心XSS。

CSRF防御：令牌机制的正确落地

Yii默认开启CSRF验证，这是很多新手部署后遇到400错误的原因，但也恰恰说明防护在起作用。框架的CsrfTokenManager生成的是真正的随机令牌，不是简单的session ID哈希。每次请求验证时，会比较客户端提交的_token参数和服务器存储的令牌值。

实际开发中容易出问题的是AJAX请求。Yii要求所有非GET请求都携带CSRF令牌，前端需要主动获取。标准做法是在页面头部用meta标签存储令牌值：

然后JavaScript全局配置AJAX请求头：

$.ajaxSetup({
    data: {
        _csrf: yii.getCsrfToken()
    }
});

或者直接在请求头里传X-CSRF-Token。对于纯API场景，如果使用JWT等无状态认证，可以在控制器beforeAction里临时关闭特定动作的CSRF验证，但必须确保该动作有其他身份校验机制。关闭方法是在控制器里设置public $enableCsrfValidation = false，或者更精细地在beforeAction里按动作判断。

加密与哈希：密码处理的正确姿势

Yii的安全组件里，yii\base\Security类承担了所有加密相关职责。密码哈希方面，它封装了password_hash和password_verify函数，自动使用bcrypt算法，成本因子默认13。这个值在保证安全的前提下兼顾了性能，每增加1，计算时间翻倍。generatePasswordHash方法接收明文密码，返回60字符的哈希串，包含算法标识、盐值和哈希结果。验证时用validatePassword，不需要手动提取盐值。

数据加密方面，Security类提供了encryptByKey和decryptByKey方法。底层使用的是openssl_encrypt，AES-256-CBC算法。密钥通过HKDF派生，初始化向量随机生成并附在密文前。这意味着每次加密相同内容，输出的密文都不同，有效防止重放攻击。实际使用时，建议在应用配置里定义统一的加密密钥，存储在安全位置而非代码仓库：

'components' => [
    'security' => [
        'class' => 'yii\base\Security',
        'passwordHashStrategy' => 'bcrypt',
    ],
],

对于需要可逆加密的敏感字段，比如用户手机号，可以在模型的beforeSave里加密、afterFind里解密，业务逻辑层完全无感。

SQL注入防护：不止是参数绑定

Yii的查询构建器和ActiveRecord默认使用PDO参数绑定，这是防御SQL注入的基础。但框架安全组件还提供了更主动的防护手段。yii\db\Expression虽然允许写原生SQL表达式，但配合yii\db\QueryBuilder的quoteValue和quoteColumnName方法，能安全地拼接动态表名或列名。这些场景参数绑定无法覆盖，因为表名和列名不能作为绑定参数。

对于必须执行的复杂原生查询，Yii提供了createCommand的bindValues方法，支持按数据类型绑定：

Yii::$app->db->createCommand('SELECT * FROM user WHERE status=:status AND created_at>:time')
    ->bindValue(':status', $status, \PDO::PARAM_INT)
    ->bindValue(':time', $time, \PDO::PARAM_STR)
    ->queryAll();

显式指定数据类型能防止PDO的隐式类型转换带来的潜在风险。另外，yii\helpers\FormatConverter类能对输出数据进行类型约束，比如确保ID字段一定是整数，这在API输出时特别有用。

安全头与响应控制

Yii的response组件允许集中配置安全相关的HTTP头。在应用配置的response部分，可以设置X-Frame-Options防止点击劫持，X-Content-Type-Options防止MIME类型嗅探，X-XSS-Protection启用浏览器内置过滤。这些头信息虽然不复杂，但统一配置能避免遗漏。

更值得关注的是Content-Security-Policy头的配置。Yii没有内置CSP构建器，但可以通过自定义过滤器实现。建议创建一个CspFilter，在afterAction里根据页面内容动态生成策略。对于内联脚本较多的后台系统，可以结合nonce机制，在每次请求时生成随机值，同时注入到CSP头和script标签的nonce属性里。这个随机值可以用Security类的generateRandomString方法生成，32位十六进制字符串足够安全。

文件上传安全也是容易被忽视的点。yii\validators\FileValidator不仅能限制文件大小和扩展名，还能检查MIME类型。但要注意，MIME类型来自客户端，不可信。更可靠的做法是结合yii\helpers\BaseFileHelper的getMimeType方法，在服务端通过文件内容检测真实类型。对于图片上传，建议使用ImageMagick或GD库重新处理，去除可能嵌入的恶意代码。

审计与日志：安全事件的追溯能力

安全组件的最后一块拼图是日志记录。Yii的日志系统支持分级和分类，安全相关事件应该使用专门的category，比如security或access。在用户登录成功、失败、权限变更、敏感操作时，手动记录日志：

Yii::info('User ' . $user->id . ' changed password', 'security');
Yii::warning('Failed login attempt from IP ' . Yii::$app->request->userIP, 'security');

配合yii\log\DbTarget，这些日志直接写入数据库，方便后续分析和告警。对于生产环境，建议配置日志路由，将security类别的日志同时发送到文件、数据库和监控系统。yii\log\EmailTarget可以在检测到严重安全事件时实时通知管理员，但需要设置合理的阈值避免邮件轰炸。

Yii的安全组件设计哲学是“约定优于配置，但保留配置能力”。默认配置下，框架已经提供了CSRF防护、XSS过滤、SQL注入防御和安全的密码哈希。开发者需要做的是理解每个组件的工作原理，在业务需求超出默认保护范围时，知道如何扩展和调整。安全不是一次性的配置，而是贯穿开发始终的意识。Yii提供的这些工具，让这种意识有了落地的支点。