各框架對策
Next.js 資安 — 正式環境的加固參考
Next.js 正式環境的加固參考：優先順序清單，加上伺服器與用戶端的邊界與環境變數、相依套件 CVE、Server Actions 授權、SSRF、標頭／CSP，以及速率限制，並附上自我驗證清單。以防禦為主，不含攻擊步驟。
適用對象：任何在經營 Next.js 應用程式的人（假設使用 App Router）。這裡不談攻擊步驟——這是一份加固用的可實作參考：依優先順序排列的清單、各面向的指引，以及自我驗證。想看跨框架的全貌，請見 各框架資安對策的入口。
依優先順序排列的加固清單
由上而下處理這張表。P0 是前提，P1 是最常見的事故來源，P2 是持續性的維運衛生。
P0 ── 前提（先做這個）
機密僅留在伺服器／相依套件 CVE 監控＋迅速修補／鞏固正式環境設定
P1 ── 最主要的事故來源
Server Actions／Route Handlers 授權＋輸入驗證／伺服器端抓取的 SSRF
P2 ── 維運衛生
標頭／CSP／驗證、工作階段、cookie／速率限制
| 優先度 | 控制項 | 具體做法（Next.js） |
|---|---|---|
| P0 | 機密僅留在伺服器 | 只有可安全載入瀏覽器的值才加 NEXT_PUBLIC_；機密只放在 Server Component／Action／Route Handler |
| P0 | 相依套件 CVE | 用 npm audit／osv-scanner 監控；以正在運行的版本判定，迅速修補。跟上核心 RCE |
| P0 | 正式環境設定 | 執行正式環境建置；別在錯誤中洩漏內部資訊（stack／env） |
| P1 | Action 授權 | 每個 Server Action／Route Handler 都要有驗證＋限定擁有者範圍的授權 |
| P1 | 輸入驗證 | 對輸入做 schema 驗證（型別／範圍／允許值）。別信任用戶端 |
| P1 | SSRF 防護 | 把伺服器端 URL 抓取限制在允許清單＋阻擋內部 IP／中繼資料。限制圖片的遠端 pattern |
| P2 | 標頭／CSP | 在 next.config 設定安全標頭＋HSTS。App Router 上可考慮以 nonce 為基礎的 CSP |
| P2 | 驗證／cookie | 工作階段 cookie 設定 Secure／HttpOnly／SameSite。別把授權只交給 middleware |
| P2 | 速率限制 | 對驗證、Server Actions 與 Route Handlers 設限 |
1. 伺服器與用戶端的邊界與環境變數（P0）
Next.js 最大的事故來源，是本應僅留在伺服器的機密最後跑到了用戶端。
- **只有可安全載入瀏覽器的值才加
NEXT_PUBLIC_。**API 金鑰或連線資訊絕不加（NEXT_PUBLIC_的值會在建置時被燒進用戶端 bundle，訪客看得見）。 - 機密只在 Server Components／Server Actions／Route Handlers 內讀取，並讓它們遠離
props與回應（序列化後的值）。 - 讓伺服器專用的模組不被用戶端匯入（不小心含入可能把機密打包進去）。請見 .env 檔案與機密。
2. 相依套件 CVE 與核心（P0）
- 用
npm audit或 osv-scanner 對相依套件（npm）的 CVE 做機器監控，以正在運行的版本判定，並迅速修補（依實際安裝的東西判斷，而非 package.json 的宣告）。 - Next.js 核心曾出現嚴重的 RCE，所以一旦有公開就要迅速跟上。關於維運紀律，請見 不在 CVE 上掉隊；至於實務，請見 漏洞應變實務手冊。
- 讓 Node／Next 維持在受支援的版本，別放著 EOL 版本不管。
3. Server Actions／Route Handlers（授權＋驗證，P1）
這些是**公開的伺服器入口。**能被呼叫不等於被允許。
常見（危險）
- 把 action 當成「有登入＝被允許」
- 只依賴 middleware 的驗證，沒有擁有者檢查
- 未經驗證就把輸入傳給 DB 或外部呼叫
- 原封不動地信任用戶端提供的值（ID、旗標）
正確
- 每個 action／handler 都要有驗證，加上限定擁有者／權限範圍的授權
- 別交給 middleware（在資料附近做授權）
- 對輸入做 schema 驗證（型別／範圍／允許值）
- 在伺服器端重新驗證，讓替換 ID 的手法無效
請見 什麼是 IDOR。在每一條讀取／更新／刪除的路徑上都做擁有者檢查。
4. SSRF 與伺服器端抓取（P1）
在伺服器端抓取使用者提供的 URL（圖片代理、webhook、抓取中繼資料）是 SSRF 的入口。
- 把目標限制在允許清單，並在連線時阻擋觸達私有 IP 與雲端中繼資料（169.254.169.254）。
- 把圖片最佳化的遠端 pattern 保持在最少（別允許抓取任意主機）。
- 請見 什麼是 SSRF。本站讓對外抓取都通過一個 SSRF 安全閘道。
5. 注入與輸出
- XSS：React 預設會跳脫輸出。別把使用者輸入傳給
dangerouslySetInnerHTML（若真有需要，僅在清理後再用）。請見 什麼是 XSS。 - SQL／注入：用 ORM／參數佔位符綁定；絕不用字串串接來組查詢（→ 什麼是 SQL 注入）。
- 別把外部輸入傳給
eval這類危險的求值。
6. 安全標頭與 CSP（P2）
- 在
next.config設定安全標頭（X-Content-Type-Options 等）與 HSTS。用 安全標頭檢查工具 檢查你自己的網站。 - 在 App Router 上，可考慮以 nonce 為基礎的 CSP（避免全面允許 inline script）。請注意，要與分析／廣告標籤共存需要一些設計。
7. 驗證、工作階段、cookie（P2）
- 在工作階段 cookie 上設定 Secure／HttpOnly／SameSite。
- 別把授權只交給 middleware 的驗證——middleware 只是補強；在 action／handler／資料層驗證實際的判斷（某些路徑可能繞過 middleware）。
- 登入時適當地重新產生並讓工作階段過期。
8. 速率限制（P2）
- 對驗證、Server Actions 與 Route Handlers 套用嘗試／流量限制，以抑制暴力破解、濫用與 DoS。
驗證：你的 Next.js 真的加固好了嗎？
做出來還不是結束——只有在檢查過之後才算完成。以下是針對你自己網站／環境的防禦性自我檢查。
沒有機密洩漏到用戶端
NEXT_PUBLIC_。正式環境不在錯誤時洩漏內部資訊
Action 授權站得住腳
標頭、相依套件、SSRF
npm audit／osv 乾淨，且對外抓取無法觸達內部 IP。本站的觀點：要管理的是『邊界與相依套件』，而非核心
本站跑在 Next.js 上，防禦的重心不是花俏的設定，而是伺服器與用戶端的邊界，以及相依套件的鮮度。機密留在伺服器，公開入口（Server Actions／Route Handlers）一律附上授權與輸入驗證，相依套件在每次部署前都做 CVE 稽核。本站自身的出身正是一起「放任的 CVE 被自動利用」的事故，所以對相依套件做機器監控是最優先的習慣。對外的 URL 抓取都通過一個 SSRF 安全閘道，讓它們無法觸達內部 IP 或中繼資料。
接下來讀
- 入口：各框架資安對策 · Laravel 資安對策
- 相依套件：不在 CVE 上掉隊 · 漏洞應變實務手冊
- 名詞：什麼是 IDOR · 什麼是 SSRF · .env 檔案與機密 · XSS
- 工具：安全標頭檢查工具
FAQ
Q要保護 Next.js，我該先做什麼？
三個 P0 項目：(1) 讓機密僅留在伺服器（只有可安全載入瀏覽器的值才加 NEXT_PUBLIC_，API 金鑰或連線資訊絕不加）；(2) 對相依套件 CVE 做機器監控，以正在運行的版本判定，並迅速修補（含核心 RCE）；(3) 鞏固正式環境設定（執行正式環境建置；別在錯誤中洩漏內部資訊）。接著再進到 Server Actions／Route Handlers 的授權與輸入驗證，以及 SSRF 防護。
Q環境變數該怎麼安全處理？
原則是『機密留在伺服器』。只有可安全載入瀏覽器的值才加 NEXT_PUBLIC_，API 金鑰或連線資訊絕不加（NEXT_PUBLIC_ 的值會在建置時被燒進用戶端 bundle，訪客看得見）。機密只在伺服器元件／Server Actions／Route Handlers 內讀取，並在設計上讓它們絕不會混進 props 或回應。
Q使用 Server Actions 要注意什麼？
Server Actions 和 Route Handlers 是公開的伺服器入口。能被呼叫不等於被允許。除了登入（驗證），還要寫上把每個操作範圍限定到擁有者的授權，並務必驗證輸入（例如 schema 驗證）。別只依賴 middleware 的驗證——在 action／handler 裡也要做擁有者檢查。
Q我該如何為 SSRF 做準備？
主要入口是在伺服器端抓取使用者提供的 URL（圖片代理、webhook、抓取中繼資料）。把目標限制在允許清單，並在連線時阻擋觸達私有 IP 與雲端中繼資料（169.254.169.254）。把圖片最佳化的遠端 pattern 保持在最少。細節請見名詞說明。
Qnpm 相依套件的漏洞該如何管理？
用 npm audit 或 osv-scanner 對已知 CVE 做機器監控，以正在運行的版本判定，並迅速修補（依實際安裝的東西判斷，而非 package.json 的宣告）。Next.js 核心曾出現嚴重的 RCE，所以迅速跟進很重要。同時讓 Node／Next 維持在受支援的版本，別放著 EOL 版本不管。