Laravel 資安對策 — .env 外洩、APP_DEBUG 與授權

Laravel 三大資安陷阱——.env 從公開目錄被暴露、正式環境開著 APP_DEBUG、缺少授權（IDOR／Mass Assignment）——以及如何一一補上。以防禦視角出發，不含攻擊步驟。

發布於 2026-07-02 更新於 2026-07-02 閱讀時間 2 分鐘

適用對象：任何在經營 Laravel 應用程式的人。這裡不談攻擊步驟——只講**三大維運事故，以及如何一一補上。**想看完整全貌，請見各框架資安對策的入口。

三大陷阱（預設值救不了你的地方）

Laravel 的跳脫與驗證都很優秀，但這三點得靠你自己補上。

① 機密被暴露

.env、備份或金鑰能從 public/ 透過網址讀取。放錯一步＝立即外洩。

② 正式環境開著除錯

APP_DEBUG=true 會在錯誤頁面上暴露環境變數與連線資訊。透過刻意觸發錯誤被抓出。

③ 缺少授權

已驗證卻沒有依擁有者範圍界定（IDOR）／Mass Assignment 覆寫 is_admin 等欄位。

經營 Laravel 時最常見的三大事故——全都在預設值之外。

如何補上（3 步驟）

把機密移到公開目錄之外（權限 600）

Laravel 本來就把 .env 放在文件根目錄之外，但別不小心把備份、匯出檔或金鑰檔放進 public/。把機密放在應用程式根目錄之外，權限設 600（僅擁有者可讀）。（→ 別把機密資訊放進公開目錄 · .env 完整外洩的案例）

正式環境關閉除錯＋快取設定

確保 APP_DEBUG=false 與 APP_ENV=production。用設定快取把它固定下來，並停止對外顯示詳細錯誤。把它納入部署步驟，每次都驗證。

建立授權（Policy/Gate＋$fillable）

別停在『登入就等於允許』。用 Policy/Gate 實作擁有者檢查，每次讀取／更新／刪除都以 user_id 等界定範圍。對於 Mass Assignment，宣告 $fillable 以防止非預期的欄位被覆寫。（→ IDOR 是什麼）

常見（危險）

備份或金鑰放在 public/，能透過網址讀取
正式環境擱著 APP_DEBUG=true
沒有授權——『登入＝看得到』
Model::create($request->all()) 接受每一個欄位

正確

機密放在文件根目錄之外，權限 600
正式環境關閉除錯＋設定快取
Policy/Gate 依擁有者界定範圍
宣告 $fillable 以擋下 Mass Assignment

本站的觀點：穩固只到預設值；授權要靠你自己

Laravel 有許多好的預設值，但授權——誰可以做什麼——是應用程式特有的，所以沒有任何框架能自動替你守。我們反覆看到的事故，與其說是 SQLi 或 XSS，不如說是『有驗證，卻沒有擁有者檢查』這一類。所以重心不在花俏的設定，而在那件不起眼的工作：每次讀取／更新都依擁有者界定範圍。再加上把機密擋在公開面之外、關閉正式環境的除錯，光靠這三點就能防住多數真實世界的 Laravel 事故。

接下來讀

FAQ

QLaravel 是安全的框架嗎？

Laravel 內建許多安全的預設值（跳脫、驗證），開箱即用就相當穩固。但『安全的預設值』和『安全的維運』是兩回事，真實事故並非來自核心，而是來自設定與維運。.env／機密被暴露、正式環境開著除錯、授權做得單薄，都是框架不會替你顧到的領域。你不能只靠預設值——這三點得靠你自己補上。

Q帶著 APP_DEBUG=true 上線有什麼危險？

開著除錯時，錯誤頁面除了堆疊追蹤，還可能顯示環境變數與連線資訊等內部機密。攻擊者可以刻意觸發錯誤把它們抓出來。在正式環境，務必設定 APP_DEBUG=false 並快取設定（config cache）讓它固定下來，同時停止對外顯示詳細錯誤。

Q為什麼『只要登入就看得到』很危險？

那是有驗證卻沒有授權。即便登入了，如果資料沒有依使用者範圍界定（例如以 user_id 界定），把網址裡的 ID 換掉就可能看到別人的資料（IDOR）。在 Laravel 中，用 Policy/Gate 實作擁有者檢查，並宣告 $fillable 來防止 Mass Assignment 覆寫非預期的欄位。