必须手动排查日志是否泄露敏感信息：先定位日志路径（如Laravel的config/logging.php或ThinkPHP的LOG_PATH），再用grep/awk/ripgrep扫描password、token、key等关键词，结合上下文验证是否真实泄露，并检查APP_DEBUG是否开启。
排查PHP框架日志文件中是否泄露数据库密码、API密钥、用户Token等敏感信息，是安全审计中最基础也最易被忽视的环节——开发环境未清理的日志可能直接暴露生产系统全部凭证。
定位框架默认日志存储路径
打开项目根目录下的config/或app/目录，查找logging.php、log.php或logger.yml等配置文件；Laravel通常在config/logging.php中定义channels.stack.path，ThinkPHP日志路径由LOG_PATH常量控制，默认值为runtime/log/。
若找不到显式配置，执行grep -r "error_log\|file_put_contents\|Log::" app/ --include="*.php"，重点查看日志写入逻辑是否硬编码路径。
这一步必须手动确认，不能依赖IDE全局搜索，因为有些框架（如CodeIgniter）会把日志路径拼接在system/core/Log.php里，且用FCPATH . 'logs/'动态生成。
立即学习“PHP免费学习笔记（深入）”；
提取日志中高频敏感关键词
方法一：用grep快速扫描
进入日志目录后运行：grep -r -i "password\|pwd\|secret\|key\|token\|auth\|cookie\|session_id\|jwt\|bearer" . --include="*.log"。注意--include="*.log"必须加上，否则会递归扫描所有文件，包括压缩包和缓存文件，导致误报爆炸。
方法二：用awk匹配结构化字段
对JSON格式日志（如Laravel的daily通道），执行：awk '/"message":.*["'\''].*password.*["'\'']/ {print FILENAME ":" NR ": " <p>对JSON格式日志（如Laravel的<code>daily通道），执行：awk '/"message":.*["'\''].*password.*["'\'']/ {print FILENAME ":" NR ": " $0}' *.log。这条命令只匹配"message"字段内含password的行，避免把URL参数里的password=123当成真实凭证——但前提是日志确实以JSON格式输出，否则会漏检。
"message"字段内含password的行，避免把URL参数里的password=123当成真实凭证——但前提是日志确实以JSON格式输出，否则会漏检。
方法三：用ripgrep提升效率
安装rg后运行：rg -i '(?P<secret>(?:[a-zA-Z0-9+/]{40,}|[0-9a-f]{32,}))' --max-file-size 10M *.log</secret>。它能识别长Base64字符串或MD5/SHA哈希，这类值大概率是密钥或Token；【--max-file-size 10M必须加，否则扫描几百MB的debug.log会卡死终端】。
验证疑似敏感内容是否真实可利用
第一步：检查上下文时间戳
找到含DB_PASSWORD的行后，用sed -n '10,20p' laravel-2024-05-12.log查看前后10行，确认该行是否出现在SQLSTATE[HY000] [1045]错误堆栈中——如果是，说明密码已被明文记录在认证失败日志里，属于高危泄漏。
第二步：比对代码中的实际变量名
在.env文件中查找DB_PASSWORD=右侧值，再回到日志中搜索该完整字符串；如果日志里出现的是DB_PASSWORD=abc123!而非DB_PASSWORD=******，说明框架未启用日志脱敏，【该日志文件必须立即删除并重置数据库密码】。
第三步：测试是否残留调试开关
搜索APP_DEBUG=true是否存在于当前生效的.env文件中；若存在，且日志包含vendor/composer/autoload_classmap.php等路径，证明调试模式开启，错误页面可能已暴露完整环境变量——此时需同步检查storage/logs/laravel.log是否包含$_ENV或getenv()调用结果。
