ThinkPHP日志泄露风险源于runtime目录Web可访问、路径配置不当、内容未脱敏及运行权限过高；应将其移出Web根目录、校验写入权限、关闭非必要日志、过滤敏感字段，并以最小权限运行PHP进程。
日志文件被 Web 服务器直接访问导致泄露
ThinkPHP 默认把日志写入 runtime/log/，而该目录若位于 Web 可访问路径（如 Apache 的 DocumentRoot 或 Nginx 的 root 下），且未做路径隔离或权限限制，攻击者可通过构造 URL（如 /runtime/log/202405/01.log）直接下载日志，暴露 SQL、密钥、用户凭证等敏感信息。
解决核心是「让日志目录不可被 Web 访问」，而非仅靠 .htaccess 或 location 阻止——因为配置遗漏、重写规则失效、或新部署时忘记同步都可能破防。
- 将
runtime目录移出 Web 根目录：例如把项目部署为/var/www/myapp/，Web 服务器 root 指向/var/www/myapp/public/，再把runtime放在/var/www/myapp/runtime/（与public同级），确保其不在任何 URI 映射路径中 - 若必须保留在 Web 目录内（极不推荐），至少用 Nginx 的
location ^~ /runtime/或 Apache 的<Directory>显式拒绝所有请求，并验证返回 403 而非 404（避免暴露目录存在） - 切勿依赖
.htaccess：ThinkPHP 的 CLI 环境或某些容器镜像可能禁用 mod_rewrite，且该文件易被误删或权限覆盖
日志路径配置不当引发写入失败或越权
ThinkPHP 通过 log.path 配置项控制日志根目录，默认值为 APP_PATH . 'runtime' . DS . 'log' . DS。若手动修改该路径但未校验父目录权限或路径合法性，会导致日志静默丢弃——既不报错也不写入，问题难以排查。
常见错误包括：
立即学习“PHP免费学习笔记（深入）”；
- 路径含相对符号（如
../../logs）：TP 不做路径规范化校验，可能被用于目录穿越，尤其在多租户或动态配置场景下风险放大 - 使用绝对路径但 Web 进程无写权限：例如设为
/data/logs/myapp，但 PHP-FPM 运行用户（如www-data）对该目录无w权限，file_put_contents失败且不抛异常 - 路径跨文件系统挂载点：某些云主机或容器中，
/tmp是 tmpfs，频繁写日志可能触发 inodes 耗尽或磁盘配额超限
建议做法：启动时用 is_writable() 主动检测 log.path 目录，失败则 error_log("Log path not writable: " . config('log.path')) 并退出；生产环境禁止使用 ./ 或 ../ 开头的路径。
日志内容未脱敏导致敏感字段明文落盘
ThinkPHP 的 Log::record() 和框架自动记录（如 SQL 日志、异常堆栈）默认不清洗敏感字段。当开启 log.sql 或 log.trace 时，$_POST、$_SERVER['HTTP_AUTHORIZATION']、数据库连接串、JWT token 等可能完整写入日志文件。
关键控制点：
- 关闭非必要日志级别：生产环境应设
log.level = 'error'，禁用debug和sql；若需临时开sql，务必配合log.sql_filter过滤关键词（如password,token,auth） - 自定义日志处理器：继承
think\log\driver\File，重写write()方法，在写入前用正则替换敏感模式（如/('password'|'token')\s*:\s*["\'].*?["\']/i） - 避免在日志中手动拼接敏感变量：不要写
Log::info("user login: " . $password)，改用结构化日志并声明 redact 字段
运行用户权限过高导致日志可篡改或提权
若 PHP 进程以 root 或高权限用户运行，且日志目录属主为该用户，攻击者一旦突破 Web 层（如通过反序列化漏洞拿到代码执行），可直接覆盖日志文件伪造审计痕迹，甚至写入 Webshell 到日志中再包含执行（如 Apache 的 mod_include + SSI 注入）。
最小权限实践：
- PHP-FPM 使用独立低权限用户（如
php-app），该用户仅对runtime/有rwx，对代码目录只读，对系统目录无访问权 -
runtime目录权限设为750，属主为php-app，属组为www-data（仅限需共享读取的场景），禁止 world 可读 - 定期检查日志文件 mtime 和 inode 是否异常变动，配合 inotify 或 auditd 监控
runtime/log/下的openat、write系统调用
权限和路径问题从来不是孤立的——一个可写的日志目录，如果同时能被 Web 访问、又没做内容过滤、还跑在高权限用户下，等于给攻击者配齐了四把钥匙。
