ThinkPHP项目安全漏洞包括：.env文件未被Web服务器禁止访问导致密钥泄露；APP_KEY硬编码在config/app.php中且长度不符AES-128-CBC要求的16字节；日志记录数据库密码等敏感信息。
ThinkPHP 项目中 .env 文件被直接访问导致密钥泄漏
只要 Web 服务器没禁掉，.env 就能被 curl 或浏览器直读——这不是 ThinkPHP 的 bug，是部署疏忽。默认情况下，Apache/Nginx 都不拦截 .env，尤其用宝塔、AMH 这类面板一键部署时，几乎必现。
- 确认是否可访问：在浏览器打开
https://your-domain.com/.env，如果返回明文配置（含APP_KEY、数据库密码），立刻处理 - Nginx 用户加这行到站点配置的
server块里：location ~ /\.env { deny all; } - Apache 用户在项目根目录
.htaccess加：RedirectMatch 403 \.env$（确保mod_alias已启用） - 别依赖 ThinkPHP 自身的「加载保护」——它只管不加载，不管文件能不能被下载
ThinkPHP 5.1+ 的 APP_KEY 被硬编码进 config/app.php 导致泄露
有人把 APP_KEY 写死在 config/app.php 里，还提交到 Git，等于把加密钥匙贴在门上。这个值一旦泄露，攻击者就能解密所有 cookie、session、cache 中的加密数据。
-
APP_KEY必须从环境变量读取，例如：'key' => env('APP_KEY', '1234567890123456'), - 生成强密钥用命令：
php think optimize:app_key（TP6）或手动运行base64_encode(random_bytes(32)) - 切勿用时间戳、项目名、常见单词拼接——
md5('thinkphp')这种等于没设 - Git 提交前检查：
git grep -i 'app_key\|key.*=' config/ app/，确保没明文残留
ThinkPHP 使用 encrypt 类加密敏感字段但未校验 APP_KEY 长度
think\helper\Str::encrypt() 和 think\helper\Str::decrypt() 底层走的是 OpenSSL AES-128-CBC，要求 APP_KEY 必须是 16 字节（128 位）。长度不对不会报错，但解密结果全是乱码或空字符串，线上排查极难定位。
- 验证长度：在控制器里临时加一行
dump(strlen(env('APP_KEY')));，必须输出16 - 若用 base64 编码生成，注意 base64 解码后才是真实字节长度，比如
base64_encode(random_bytes(16))生成的字符串长度是 24，但解码后是 16 - TP6 推荐用内置命令生成：
php think optimize:app_key --length=16，避免手误 - 不要为了“看着整齐”截断或补零——
substr($key, 0, 16)或str_pad($key, 16, '0')都会破坏安全性
ThinkPHP 日志中意外记录数据库密码或 API Key
当数据库连接失败或 HTTP 请求异常时，ThinkPHP 默认会把完整配置数组写进 runtime/log/，包括 database.password 和 http_options.headers.Authorization 这类字段。
立即学习“PHP免费学习笔记（深入）”；
- 在
config/app.php中关闭敏感字段日志：设置'log' => ['record' => false]并单独配置需记录的 key，或重写think\Log类过滤逻辑 - 更稳妥的做法是，在
config/database.php中改用env('DB_PASSWORD')，再配合 Log 驱动的ignore_data配置项（TP6.1+ 支持） - 检查
runtime/log/目录权限：必须是640或更严，禁止 Web 进程以外用户读取 - CI/CD 流水线里跑测试时，别用生产环境
.env——本地 mock 配置比修复日志泄露快得多
环境变量读取、密钥长度、日志过滤，这三处不是独立问题，而是一条泄漏链：一个点松动，整个加密体系就形同虚设。尤其 APP_KEY 长度错误这种，连报错都没有，只能靠人工卡点验证。
