Laravel 应用的 .env 被暴露给全世界——共享虚拟主机上最常见的部署错误

本文把共享虚拟主机上现实中经常发生的配置错误，作为一个隐去了域名和具体数值的案例当作教训来讲。这不是去找别人网站的事。目的是「让自己的（或接手的）部署变得安全」。

当时发生了什么

在共享虚拟主机上，许多 Laravel 应用都是这样部署的。把危险的部署和正确的部署并列对比：

~/public_html/
└── app/          ← 整个 Laravel(错误)
    ├── .env      ← 通过 /app/.env 能读到
    ├── .git/     ← clone 即可连历史一起还原
    ├── vendor/  config/  storage/
    └── public/   ← 其实「只该」放这里

~/laravel/app/    ← 本体在公开根目录之外
├── .env  .git/   ← HTTP 够不到=安全
└── public/       ← 只把这里用 symlink 公开
        └── index.php

从外部能以 200 OK 取得的典型文件：

修复方法：三个阶段

Step 1 — 应急处置：用 .htaccess 在 HTTP 层面切断危险文件

先把「继续泄露」止住。这一步可逆，不影响正常显示。在 public_html/.htaccess 开头加上拒绝访问机密文件的代码块（防御目的的配置示例）：

# === SECURITY BLOCK ===
# .env / .git 配下を 404 に
RedirectMatch 404 (?i)/\.(env|git)(\..*)?(/|$)
 
# バックアップ・ダンプ・認証ファイルを拒否
<FilesMatch "(?i)\.(sql|sql\.gz|bak|old|swp|save|orig|tgz)$|^credentials\.json$|\.bk[._]">
    Require all denied
</FilesMatch>
 
# Laravel の内部ディレクトリが /<app>/storage/... 等で見えていた場合
RedirectMatch 403 (?i)^/[^/]+/(storage|bootstrap/cache|config|database|resources|routes|tests|vendor)(/|$)
# === END ===

不过黑名单本质上就是打地鼠。忘了堵 composer.lock、用新命名的文件又多出漏洞——这些必然会发生。把它当作「尽力而为的止血」，真正的解决方案放在 Step 3。

Step 2 — 密钥轮换（按已泄露的前提）

即便用 .htaccess 堵上了，也要按已经被看到的前提来处理。按高风险优先顺序：

1. 外部 API 密钥（最优先・立即）：直接关系到计费和账号被劫持。OAuth 的 CLIENT_SECRET、各种 API 密钥、云认证凭据都要作废＋重新签发＋按最小权限设置。
2. OAuth 客户端密钥。
3. APP_KEY：重新生成会导致会话失效，还可能让已加密的数据库列无法解密，因此要先确认影响范围。
4. 邮件 SMTP、数据库认证凭据。

Step 3 — 结构改造：把应用本体移到 docroot 之外（真正的解决方案）

把每个应用这样重新部署：

# 1. 本体を公開ルートの外へ（同一ファイルシステムなら mv は一瞬で atomic）
mv ~/example/public_html/app  ~/example/app-laravel
 
# 2. 公開ルートには最小の bootstrap だけ置く
mkdir -p ~/example/public_html/sub
cat > ~/example/public_html/sub/index.php <<'PHP'
<?php require __DIR__ . '/../../app-laravel/public/index.php';
PHP
# 3. Laravel public/.htaccess をコピー、静的アセットを symlink、設定キャッシュをクリア

变成这种形态后，.env、.git、vendor/ 本身就不在公开根目录里，因此不依赖 .htaccess 规则也安全。具体步骤整理在了 在虚拟主机上不让 .env 被公开的部署与配置。

路上那些“教科书里没写”的坑

• 子域名的作用域问题：对已注册子域名的 docroot 事后用 symlink 指向另一棵目录树，可能不会跟随生效而返回 500。→ 让 docroot 保持为真实目录，从里面的小 index.php 用绝对路径 require 去读取的「bootstrap-redirect 型」更稳定。
• opcache 会一直记住坏掉的状态：opcache 把 index.php 的加载失败记了下来，即便重建也可能持续返回 500。最后的手段是改文件名（如 entry.php 等）。
• 「未注册子域名」的 docroot 能通过父域名读到：即便 https://sub.example/ 无效，https://example/sub/ 也能看到内容，这是容易被忽略的入口。排查时要把经父域名的路径也一并堵上。
• 把秘密值硬编码进 config/*.php：与 .git 公开叠加在一起，就能从历史里还原所有轮换记录。要始终经由 env()，并且不要在 fallback 默认值里写真实值。

最大的教训：这不是「个人的失误」

虚拟主机萌芽期的「把所有东西放到 public_html 正下方」的文化，与前提是只暴露 public/ 的 Laravel 相遇，结果**「把应用本体放在 public_html/<app>/、再暴露其下的 public/」这种危险的部署事实上成了标准**。各家官方文档里举的例子也尽是「把项目放进 public_html 里」，更是火上浇油。

所以对策不能靠个人的注意力，而要做成机制：

接下来读

• 术语：.env（环境变量文件）是什么 / CVE 是什么
• 对策：在虚拟主机上不让 .env 被公开的部署与配置
• 事故：用 AI 写的代码泄露了 API 密钥（泄露的“另一条途径”＝运行时）