各框架對策

#framework #getting started #hardening #misconfiguration

各框架的資安對策 — 依你所用技術量身打造的防禦方式

一個依框架分類的資安入口——彙整 WordPress、Laravel、Next.js、Spring 等各框架『預設的危險設定、最常被利用的弱點、加固步驟』。威脅的類型是共通的，不同的只是各框架的『預設陷阱』。以防禦視角出發，不含攻擊步驟。

發布於 2026-07-02 更新於 2026-10-06 閱讀時間 4 分鐘

本頁內容

「Laravel 資安」「WordPress 加固」——當我們搜尋時，是在尋找每一種技術各自的答案。本頁就是各框架防禦方式的入口（不含攻擊步驟）。

共通（每個框架都一樣）

存取控制、機密資訊、注入、相依套件 CVE、設定錯誤。基本的防禦也是共通的。

框架特有（各章節探討）

『危險預設值』與『該技術最常被鎖定的位置』。依技術而異的只有這一塊。

無論哪個框架，『弱點類型』都是共通的——不同的只有危險預設值與被鎖定的位置。

每個框架共通的弱點類型

先看全貌。以下這些類型不分技術都會被反覆鎖定；各框架章節會說明它們在該技術中如何呈現。

存取控制

驗證≠授權、IDOR、暴露在外的管理後台（最大的事故來源）

機密資訊

.env／金鑰外洩、明文儲存、被提交進 Git

注入

SQLi、XSS、樣板／命令注入

相依套件 CVE／設定錯誤

未修補的已知漏洞、正式環境開著除錯、危險的預設值

各框架指南

讀你這套技術的章節。每一章都依「預設的危險 → 最常被鎖定的位置 → 加固步驟」的順序展開。

WordPress

市占最大，因此是最大的攻擊目標。主要的入侵途徑：外掛／佈景主題的漏洞、跳過更新、脆弱的管理員、暴露在外的管理後台。 → WordPress 資安對策

Laravel

預設值很穩健，但事故來自維運。三大重點：.env 外洩、正式環境的 APP_DEBUG=true、缺少授權（驗證≠授權／Mass Assignment）。 → Laravel 資安對策

Next.js

預設偏安全，但事故發生在伺服器與用戶端的邊界。三大重點：環境變數的暴露、Server Actions 的授權疏漏、相依套件 CVE（含本體 RCE）。 → Next.js 資安對策

Java／Spring

框架本身成熟穩定，但使用廣泛，因此是巨大的攻擊目標。四大重點：相依套件的已知 CVE（Log4Shell 類）、Actuator 的暴露、授權設定的疏漏、不安全的反序列化。 → Spring Boot 資安對策

Express／Rails／Django／ASP.NET Core

最小主義與成熟框架各有其陷阱：自己補上的防禦、放得太寬的授權、正式環境設定、相依套件 CVE。 → Express · Ruby on Rails · Django · ASP.NET Core

正式環境最先要確認的設定（各框架速查表）

在任何框架上，都要先確認兩件事：正式環境是否會顯示詳細錯誤，以及機密資訊放在哪裡。設定名稱各不相同，請在下表找到你的那一列。名稱已對照各專案目前的官方文件確認（版本見最後一欄）。

框架	關閉詳細錯誤頁面	機密資訊放在哪裡，以及要注意的地方	常被漏掉的設定	確認的文件
WordPress	在 `wp-config.php` 把 `WP_DEBUG` 設為 `false`（預設為 false）	DB 憑證在 `wp-config.php`；絕不要在公開目錄留下副本	用 `DISALLOW_FILE_EDIT` 禁止從控制台編輯檔案；刪除不用的外掛	Advanced Administration Handbook
Laravel	在 `.env` 設定 `APP_DEBUG=false`	絕不要提交 `.env`（加密過的 `.env.encrypted` 可以）	執行 `config:cache` 後，在設定檔以外呼叫 `env()` 會拿不到值	13.x
Next.js	先 `next build` 再 `next start`；絕不要公開開發伺服器	`NEXT_PUBLIC_` 變數會被內嵌到瀏覽器的 JavaScript	機密資訊被加上了 `NEXT_PUBLIC_` 前綴	16.x
Spring Boot	不讓堆疊追蹤出現在錯誤回應中（維持預設）	透過環境變數傳入，不要寫死在設定中	Actuator 預設只透過 HTTP 公開 `health`；絕不要設定 `management.endpoints.web.exposure.include=*`	4.1
Django	`DEBUG = False`	從環境變數或檔案讀取 `SECRET_KEY`；不要放進版本控制	設定 `ALLOWED_HOSTS`；執行 `manage.py check --deploy`	6.1
Ruby on Rails	使用正式環境的設定（`config/environments/production.rb`）	`config/credentials.yml.enc` 加上 `config/master.key`；絕不要提交 master.key	用 `config.force_ssl = true` 強制 HTTPS	8.1
Express	`NODE_ENV=production` 會從預設錯誤回應中移除堆疊追蹤	透過環境變數傳入，不要寫在程式碼裡	用 `helmet` 設定安全標頭；`app.disable('x-powered-by')`	目前的官方指南
ASP.NET Core	Developer Exception Page 只在 Development 環境開啟（目前範本的預設）	使用者祕密（user secrets）是開發用；正式環境用環境變數或金鑰保存庫	絕不要在 `ASPNETCORE_ENVIRONMENT` 設為 Development 的狀態下執行正式環境	10.0

真實案例：多數事故來自跳過更新與正式環境的設定，而不是核心錯誤

最明顯的模式，不是框架本身的漏洞，而是明明有修補卻沒套用，或是開發用的設定被留在了正式環境。

Equifax（2017）：Apache Struts 漏洞（CVE-2017-5638）的修補在公開當天就已釋出，卻沒有套用到對外公開的系統，導致約 1 億 4,700 萬人的個人資料外洩（→ Equifax 外洩事件）。
Log4Shell（2021）：Java 日誌函式庫的漏洞。許多組織是透過其他元件間接引入它，因此無法判斷自己有沒有在用（→ Log4Shell）。
AI 代理案例（2026）：研究用的 AI 代理接觸到真實網站時，從暴露在外的除錯頁面讀走了憑證，而網站方並沒有察覺（→ AI 代理接觸真實網站）。

在 OWASP Top 10（2025）中，第一名是存取控制失效，第二名是安全設定錯誤，第三名是軟體供應鏈失效（你所依賴的元件中的問題）。這些在任何框架上都會發生。

如何檢查自己的網站

以下檢查只能在你自己管理的網站上進行。

開啟不存在的 URL，查看錯誤頁面

在自己的網站上開啟任意一個編造的 URL，確認沒有出現原始碼片段、檔案路徑或設定值。如果有，請依上表修正「關閉詳細錯誤頁面」的設定。

使用框架本身的檢查命令

Django 有 python manage.py check --deploy；Laravel 可以用 php artisan about --only=environment 查看除錯模式。Spring Boot 請確認設定中的 management.endpoints.web.exposure.include。

掃描相依套件與外部看得到的部分

相依套件的已知漏洞，npm 用 npm audit，Composer 用 composer audit，全部一起則用 osv-scanner（在瀏覽器上：相依套件漏洞掃描）。外部看得到的部分，安全標頭檢查會顯示缺少的標頭，網站資安總體檢則一次檢查 .env 與 .git 的暴露、憑證和 cookie 旗標。

常見錯誤與修正

常見錯誤	會發生什麼	修正方式
替機密 API 金鑰加上 `NEXT_PUBLIC_` 前綴	金鑰被內嵌到瀏覽器的 JavaScript，任何人都讀得到	拿掉前綴、只在伺服器端使用，並到發行方撤銷已外洩的金鑰
公開所有監控端點（例如 Spring Boot Actuator）	設定值與記憶體內容可以從外部讀取	只公開 `health` 之類的端點，其餘放在驗證之後
停用不用的外掛卻沒有刪除	檔案留在伺服器上，也不再收到更新	不用的就刪除
看了更新通知卻沒確認已套用	明明有修補，漏洞卻一直開著（Equifax 的模式）	更新後確認版本，並定期執行相依套件掃描

本站的觀點：事故來自框架的維運方式，而非框架本身

爭論「這個框架安不安全／危不危險」很少有幫助。多數真實事故都不是來自核心的錯誤，而是來自用法——跳過更新、機密外洩、缺少授權、危險的預設值。本站自身就跑在 Next.js 上，我們的主要防禦並沒有什麼特別之處：監控相依套件的 CVE、把機密資訊擋在程式碼與公開目錄之外、強驗證、可還原的備份。每個框架章節，都是把這些基本對策套用到該技術上。

先做好共通的基本對策

在深入某個框架章節之前，先把在任何技術上都有效的部分做好，效率最高。

入門：資安底線清單（管理員帳號、機密資訊、修補、偵測、還原）
實務：漏洞應變實務手冊 · 監控相依套件的 CVE（osv-scanner）
機密資訊：別把機密資訊放進公開目錄

出處

WordPress Advanced Administration Handbook「Hardening WordPress」與「Debugging in WordPress」— developer.wordpress.org
Laravel 13.x「Configuration」（Environment File Security / Debug Mode）— laravel.com
Next.js「How to use environment variables in Next.js」（16.x）— nextjs.org
Spring Boot 4.1「Endpoints」（Actuator 的公開範圍）— docs.spring.io
Django 6.1「Deployment checklist」— docs.djangoproject.com
Ruby on Rails Guides「Securing Rails Applications」（8.1）— guides.rubyonrails.org
Express「Production Best Practices: Security」與「Error Handling」— expressjs.com
Microsoft Learn「Handle errors in ASP.NET Core」（10.0）— learn.microsoft.com
OWASP Top 10:2025 — top10.owasp.org

接下來讀

指南：WordPress 資安對策 · Laravel 資安對策
基本對策：資安底線清單（所有框架共通）
名詞：CVE 是什麼（追蹤框架已知漏洞的單位）

FAQ

Q哪個框架最危險？

與其說有『危險的框架』，不如說有『危險的用法』。話雖如此，從攻擊者的角度看『安裝數越多＝越值得鎖定』，因此全球市占最大的平台——WordPress 及其外掛——在統計上是最常被鎖定的對象。即便如此，在任何框架上，多數事故都不是來自核心的錯誤，而是來自維運面：跳過更新、機密外洩、缺少授權、以及危險的預設值。所以與其替框架排名，把自己這套技術的危險預設值一一修正更有實益。

Q越新的框架就越安全嗎？

不一定。較新的框架往往內建更安全的預設值，但實績較淺（可能存在尚未發現的漏洞），而且開發者尚在摸索，設定錯誤也更多。歷史悠久的框架成熟且經過充分驗證，卻苦於老舊、未修補的大版本（EOL），以及外掛／相依套件所帶來的龐大攻擊面。歸根結柢，真正有效的維運是：追蹤版本、理解危險的預設值、以多層方式防禦。

Q我該從哪裡開始？

先做好所有框架共通的基本對策（監控相依套件的 CVE、把機密資訊擋在程式碼與公開目錄之外、強驗證、備份）。接著打開你實際使用的框架章節，把該技術特有的危險預設值一一修正（例如 WordPress 的外掛管理、Laravel 的 APP_DEBUG／授權）。

Q在正式環境開著除錯模式有什麼風險？

發生錯誤時，原始碼的片段、設定值和所使用的函式庫會顯示在畫面上。Laravel 的文件指出，在正式環境設定 APP_DEBUG=true 有把敏感設定值暴露給使用者的風險；Django 也說絕對不能在正式環境開啟除錯。在 2026 年公開的 AI 代理案例中，憑證就是從暴露在外的除錯頁面被讀走的。正式環境一定要關閉，再開啟一個不存在的 URL，確認沒有顯示詳細的錯誤。

Q如何確認我的框架是否有已知漏洞？

先確認你執行的版本，再整體掃描相依套件。npm 用 npm audit，PHP Composer 用 composer audit，跨語言則用 osv-scanner；本站的相依套件漏洞掃描工具也可以。已確認被利用的漏洞會被列入美國 CISA 的 KEV 目錄，所以列在 KEV 上的要最先更新。

Q可以把 API 金鑰放在 Next.js 的 NEXT_PUBLIC_ 環境變數裡嗎？

不行。如 Next.js 的文件所說明，以 NEXT_PUBLIC_ 開頭的變數會在建置時被內嵌到送往瀏覽器的 JavaScript 中，任何人都讀得到。機密金鑰不要加前綴，只在伺服器端使用；瀏覽器端需要的功能，請透過你自己的伺服器 API 處理。