csrf和xss防护在codeigniter3和4中不冲突，但配置错位或调用顺序不当会导致表单提交失败、ajax被拦截或输出被意外转义；本质是二者作用域与触发时机不同。
CodeIgniter安全机制与不足解析【安全】要求你准确识别框架内置防护能力的生效前提、边界限制和常见失效场景，避免将配置开关误认为已启用防护，防止因忽略令牌同步、驱动未启用或权限校验缺失导致真实攻击面暴露。
CSRF防护：配置≠启用，过滤器才是执行开关
第一步：打开 app/Config/Security.php，确认 $csrfProtection 已设为 'cookie' 或 'session'，但【这仅表示令牌生成就绪，不等于请求会校验】。
第二步：必须编辑 app/Config/Filters.php，在 $globals['before'] 数组中显式加入 'csrf' 过滤器，例如：public $globals = ['before' => ['csrf']];。漏掉这一步，所有 POST 请求都会绕过验证。
第三步：若需排除 API 路由，使用 'except' 时必须写成数组格式，如 ['except' => ['api/v1/*', 'health']]；写成字符串 'api/*' 会导致排除失效，整个 API 组仍被拦截。
XSS防护：输出转义不能替代输入清洗
方法一：模板中用 esc() 函数包裹变量，如 = esc($user_comment, 'html') ?>，适用于 HTML 上下文输出。
方法二：控制器中调用 $this->request->getPost(null, FILTER_SANITIZE_STRING) 获取已过滤数据，但注意该过滤器在 PHP 8.1+ 中已被弃用，【应改用 FILTER_SANITIZE_FULL_SPECIAL_CHARS 或自定义验证规则】。
方法三：启用全局 XSS 过滤（不推荐）——在 app/Config/IncomingRequest.php 中设 $globalXssFilter = true，但会带来性能损耗且无法区分上下文，可能破坏富文本内容。
会话安全：IP绑定与ID再生缺一不可
开启 sess_match_ip 和 sess_match_useragent 可防御部分会话劫持，但动态 IP 用户会频繁掉线；更关键的是登录成功后必须立即调用 $this->session->regenerate(TRUE)，否则旧会话 ID 仍可被重放。
数据库驱动下，确保 ci_sessions 表包含 ip_address 字段并启用 sess_match_ip，否则匹配逻辑永远返回 true。
使用 files 驱动时，会话文件默认存于系统临时目录，若多个应用共用同一 tmp 目录，存在跨应用会话污染风险。
公共目录敏感文件：.htaccess 不是万能锁
在 public/logs/ 下新建 .htaccess，写入：
Require all denied
如果服务器运行在 Nginx 环境，.htaccess 完全无效，必须改写 nginx.conf，在 location ~ ^/logs/.*$ { deny all; } 块中强制拦截。
当敏感文件通过 URL 直接暴露（如 /public/config-backup.php），仅靠 .htaccess 拦截不够，必须配合路由层权限控制——在控制器中检查用户角色后再读取并输出文件内容。
反序列化风险：警惕 session_decode 和 cookie 解析
1. 检查所有调用 session_decode() 的位置，确认传入数据是否完全来自 $_SESSION —— 若从 $_POST 或 $_COOKIE 中提取字符串再 decode，即构成高危反序列化入口。
2. 查看 Cookie 处理逻辑，禁用任何形如 unserialize($_COOKIE['data']) 的代码；CI4 默认不解析 Cookie 内容为对象，但自定义中间件可能绕过此保护。
3. Redis/Memcached 缓存中若存储了未签名的序列化对象，攻击者可通过篡改缓存值触发 __wakeup() 或 __destruct()，必须启用 cache 加密或改用 JSON 存储。
