CodeIgniter 4 的 CSRF 防护需正确启用过滤器、同步 AJAX 令牌并理解其局限性;仅配置不启用、忽略令牌刷新、混淆 XSS/越权等边界问题,会导致防护失效。
CodeIgniter 4 的 CSRF 防护机制本身是够用的,但“够不够”不取决于框架有没有,而取决于你是否启用、是否配对、是否绕过它自己埋的坑。
很多项目上线后才发现 CSRF 失效,根本原因不是框架不行,而是配置压根没生效:
默认情况下,app/Config/Security.php 中的 $csrfProtection 是 'cookie',但这个开关只是“准备就绪”,真正启用还得靠过滤器。
app/Config/Filters.php 中把 'csrf' 加入全局或指定方法的过滤器列表,例如:public $globals = [
'before' => [
'csrf' => ['except' => ['api/*']],
],
];$this->security->getCSRFTokenName() 却没启用过滤器,请求照样被放行——验证逻辑根本没跑。csrf_protection = TRUE 这种写法属于 CI3 风格,CI4 已废弃;继续写在 config.php 里完全无效。CSRF 令牌在普通表单中由 form_open() 自动注入,但 AJAX 场景下极易漏掉同步更新:
典型现象:第一次 AJAX 成功,第二次 403 —— 因为 CI4 默认开启 $regenerate = true(每次请求刷新令牌),而前端没拿到新值。
return $this->response->setHeader('X-CSRF-TOKEN', csrf_hash());csrf_token() 和 csrf_hash()。$.ajaxSetup({ headers: { 'X-CSRF-TOKEN': ... } }) 硬编码初始值——那是个静态快照,过期即失效。有人以为开了 CSRF 就高枕无忧,结果被 GET /user/delete?id=123 直接删库——这跟 CSRF 毫无关系。
C
SRF 防的是“用户被诱导点击恶意链接后,浏览器自动带上合法 Cookie 提交请求”,它不校验:
id 参数是否属于当前用户(水平越权)email 字段是否被前端 JS 改成 ">(XSS 漏洞)../../.htaccess(路径遍历)这些得靠 esc() 输出转义、$this->request->getPost(null, FILTER_SANITIZE_STRING) 输入清洗、权限中间件、查询构建器等组合防御。
真正容易被忽略的,是 CSRF 令牌生命周期和存储方式的隐性耦合:比如你设了 $csrfProtection = 'session',但 session 驱动用了 database,而数据库连接失败时 session 写不进去——那所有 CSRF 验证都会静默失败,变成“假防护”。这类问题不会报错,只会让安全形同虚设。