读写分离时CSRF令牌失效需设Security.php中$csrfProtection为'cookie'、禁用$regenerate、AJAX携X-CSRF-TOKEN头；XSS防护须输出时用esc()按上下文转义或HTMLPurifier过滤；权限校验必须走主库或强一致缓存；安全配置须通过配置中心统一分发防漂移。
读写分离时CSRF令牌失效怎么办
读写分离后，csrf_hash() 生成的令牌可能在从库节点上校验失败——因为 csrf_token() 和 csrf_hash() 默认依赖 session 或 cookie 存储，而 session 数据若未同步到所有从库（或被路由到无状态从库），会导致令牌验证 403。
根本原因不是 CSRF 机制本身失效，而是读写分离常伴随负载均衡和无共享 session 架构，使得请求可能落到不同节点，而 session/cookie 数据未全局一致。
- 确认
$csrfProtection在app/Config/Security.php中设为'cookie'（而非'session'），避免依赖服务端 session 同步 - 确保前端始终从同一域名下读取
csrf_cookie_name（默认ci_csrf_token），且 Cookie 的Domain和Path配置覆盖全部子节点 - 禁用
$regenerate = true（除非你明确需要每次刷新令牌），否则每次请求重生成会加剧不一致；生产环境建议设为false，配合$expires控制有效期 - AJAX 请求必须显式携带头：
X-CSRF-TOKEN: <cookie></cookie>，不能只靠表单隐藏字段——因为 AJAX 可能被路由到任意从库节点
从库查询结果被 XSS 注入怎么防
读写分离不改变数据来源风险：从库返回的数据仍是用户输入或第三方注入的原始内容。直接 = $row['content'] ?> 渲染，哪怕走的是从库，照样触发 XSS。
关键点在于「输出上下文」，跟数据从哪台数据库来无关。框架不会因为你用了从库就自动帮你转义。
- 所有动态输出必须调用
esc()，并传入正确上下文参数：esc($data, 'html')、esc($data, 'js')、esc($data, 'url') - 避免在模型层做「过滤后存库」这类操作——从库数据是只读副本，但原始污染仍在；净化必须发生在输出前，而不是入库前
- 如果视图中需渲染富文本（如编辑器内容），
esc()不够用，应引入白名单过滤（如HTMLPurifier），且该过滤必须在视图或专用服务层执行，不能绕过 - 检查是否误启了
$globalXSSFiltering = true：它会对所有输入做strip_tags()，破坏合法 HTML，且对从库读取的数据无效（只作用于 request 数据）
读写分离下如何安全验证用户权限
权限判断逻辑若只查从库，可能因主从延迟导致「刚授予权限却无法访问」或「已撤销权限仍可操作」——这不是安全漏洞本身，而是延迟引发的策略执行偏差。
权限校验属于「决策点」，必须强一致性。不能把 canEdit($postId) 这类判断交给从库。
- 所有鉴权操作（如角色检查、权限码比对、资源所有权验证）必须走主库查询，或使用缓存（如 Redis）+ 主库双写保障最终一致性
- 不要在过滤器（
Filters.php）里查从库做if (!userHasRole('admin'))—— 应改用服务层封装的主库方法，例如auth()->user()->can('update.post') - 若业务允许短暂延迟（如后台菜单显示），可用带 TTL 的缓存 + 主库更新后主动失效；但涉及写操作前的校验（如提交表单前检查是否有编辑权），必须实时查主库
- 注意
Validation规则中的is_unique等数据库约束检查，也应强制走主库，否则重复提交可能绕过校验
主从切换时的安全配置漂移风险
当主库故障触发自动切换，新主库若未同步安全配置（如 app/Config/Security.php 中的 $tokenName、$headerName），旧令牌将无法解析，导致大面积 403；更隐蔽的是，若新主库 PHP 配置缺失 open_basedir 或 disable_functions，可能暴露攻击面。
配置不是代码，不会随 Git 自动部署。运维层面的配置一致性，直接影响安全机制是否生效。
-
app/Config/Security.php必须纳入配置中心或 Ansible 等工具统一分发，禁止手动修改各节点 - 主从库的 MySQL 全局变量（如
sql_mode、secure_file_priv）需保持一致，防止利用宽松模式绕过输入校验 - 检查
php.ini中unserialize_callback_func是否为空，PHP 7.3+ 虽加强了反序列化限制，但若回调函数被设为call_user_func类型，仍可能被构造 POP 链 - 定期运行脚本比对主从节点的
php --ini和SHOW VARIABLES输出，发现漂移立即告警
