CodeIgniter 4 的 CSRF 防护需正确启用过滤器、同步 AJAX 令牌并理解其局限性；仅配置不启用、忽略令牌刷新、混淆 XSS/越权等边界问题，会导致防护失效。
CodeIgniter 4 的 CSRF 防护机制本身是够用的，但“够不够”不取决于框架有没有，而取决于你是否启用、是否配对、是否绕过它自己埋的坑。
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里完全无效。
表单提交没问题，AJAX 请求常掉坑里
CSRF 令牌在普通表单中由 form_open() 自动注入，但 AJAX 场景下极易漏掉同步更新：
典型现象：第一次 AJAX 成功，第二次 403 —— 因为 CI4 默认开启 $regenerate = true（每次请求刷新令牌），而前端没拿到新值。
-
后端需在响应头中返回新令牌：
return $this->response->setHeader('X-CSRF-TOKEN', csrf_hash()); - 前端 JS 必须监听每次响应并更新全局 token 变量，不能只在页面加载时读一次
csrf_token()和csrf_hash()。 - 别用
$.ajaxSetup({ headers: { 'X-CSRF-TOKEN': ... } })硬编码初始值——那是个静态快照，过期即失效。
CSRF 不是万能盾，它不管 XSS、越权、参数篡改
有人以为开了 CSRF 就高枕无忧，结果被 GET /user/delete?id=123 直接删库——这跟 CSRF 毫无关系。
CSRF 防的是“用户被诱导点击恶意链接后，浏览器自动带上合法 Cookie 提交请求”，它不校验：
- 请求里的
id参数是否属于当前用户（水平越权） -
email字段是否被前端 JS 改成">（XSS 漏洞） - 上传文件名是否含
../../.htaccess（路径遍历） - 数据库查询是否拼接了未过滤的 POST 数据（SQL 注入）
这些得靠 esc() 输出转义、$this->request->getPost(null, FILTER_SANITIZE_STRING) 输入清洗、权限中间件、查询构建器等组合防御。
真正容易被忽略的，是 CSRF 令牌生命周期和存储方式的隐性耦合：比如你设了 $csrfProtection = 'session'，但 session 驱动用了 database，而数据库连接失败时 session 写不进去——那所有 CSRF 验证都会静默失败，变成“假防护”。这类问题不会报错，只会让安全形同虚设。
