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 金鑰（洩漏的「另一條途徑」＝執行階段）