Next.js 的資安對策 — Server Actions、環境變數、相依套件 CVE 的守法

Next.js 的預設偏安全，但事故發生在『伺服器與用戶端的邊界』。三大＝環境變數的暴露（把伺服器專用的機密送到用戶端）／Server Actions、Route Handlers 的授權疏漏／相依套件的已知 CVE（含本體 RCE）。本文以防禦視角，講解意識到邊界、把機密限定在伺服器、擁有者檢查、CVE 監控的守法，不含攻擊步驟。

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

對象：正在維運 Next.js 應用程式的人。這裡不談攻擊步驟，只講在伺服器與用戶端的邊界所發生的事故，以及如何補起來。想看全貌，請參閱各框架資安對策的入口。

三大陷阱（發生在邊界）

Next.js 的跳脫與路由都很出色，但下面這三點是開發者要意識到邊界、自己去補的領域。

① 環境變數的暴露

誤用 NEXT_PUBLIC_，或把機密送到用戶端。被燒進 bundle，訪客看得見。

② action 的授權疏漏

Server Actions / Route Handlers 沒有擁有者檢查。替換 ID 就能操作他人的資料。

③ 相依套件的已知 CVE

放任本體／相依套件的已知漏洞（含 RCE）。以正式環境實際版本判定並迅速修補。

Next.js 最常發生的三大事故。全都與『伺服器／用戶端的邊界』有關。

補法（3 步驟）

把機密限定在伺服器

只有可以載到瀏覽器的值才加 NEXT_PUBLIC_，API 金鑰、連線資訊等機密不加。機密只在伺服器元件／Server Actions／Route Handler 內讀取，不混進 props 或回應。（→ .env 與機密資訊）

在每個 Server Action / Route Handler 確認授權

這些是公開的伺服器入口。除了登入（驗證），還要把每個操作範圍限定到目標是否真的屬於該使用者。忘了寫，替換 ID 就可能被操作他人的資料（→ 什麼是 IDOR）。輸入驗證也要在 action 內做。

對相依套件 CVE 做機器監控並迅速修補

本體／相依套件的已知漏洞要以「正式環境實際版本」判定（package.json 的下限會說謊），用機器監控及早偵測並迅速修補。事故的起點多半是放任的 CVE 被自動利用。（→ 不在 CVE 上掉隊的機制）

常見（危險）

給機密加 NEXT_PUBLIC_，暴露到用戶端
把 Server Actions 當成「有登入就能執行」
在伺服器端無防備地抓取外部 URL（SSRF）
放任相依套件的已知 CVE

正確

機密限定在伺服器、不送到用戶端
在 action 做擁有者範圍的授權
URL 抓取走SSRF 對策（阻擋內部 IP、限定允許目標）
相依套件 CVE 做機器監控＋迅速修補

本站的觀點：管理的是『邊界與相依套件』，而非本體

本站跑在 Next.js 上，實際把防禦重心放的不是花俏的設定，而是「伺服器／用戶端的邊界」與「相依套件的鮮度」。機密務必留在伺服器側，公開入口（Server Actions / Route Handlers）一定寫上授權，相依套件在每次部署前都做 CVE 稽核。本站的出身也是一起「放任的 CVE 被自動利用」的事故，所以對相依套件做機器監控是最優先的習慣。抓取外部 URL 的處理都會通過我們自製的 SSRF 安全閘道，不讓它觸達內部 IP 或中繼資料（→ 什麼是 SSRF）。

接下來讀

FAQ

QNext.js 是安全的框架嗎？

Next.js 具備輸出跳脫等安全的預設，素狀態下相對穩固。但事故並非來自本體的預設，而是來自『伺服器與用戶端的邊界』的處理方式：本應是伺服器專用的機密卻被載到用戶端、在 Server Actions 忘了寫授權、放任相依套件的已知 CVE——這三點是實際維運中的主要破口。不能一味依賴預設，你得自己管理邊界與相依套件。

Q環境變數該怎麼處理才安全？

原則是『機密只留在伺服器』。只有可以載到瀏覽器的值才加 NEXT_PUBLIC_，API 金鑰、連線資訊等機密絕對不加（NEXT_PUBLIC_ 的值會在建置時被燒進用戶端 bundle，訪客看得見）。機密只在伺服器元件／Server Actions／Route Handler 內讀取，設計上不讓它們混進 props 或回應。

Q使用 Server Actions 要注意什麼？

Server Actions 和 Route Handlers 是『公開的伺服器入口』。能被呼叫不等於允許執行。除了登入（驗證）之外，還要寫上把每個操作範圍限定到目標擁有者的授權。忘了寫，別人只要替換一個 ID 就能更新或刪除他人的資料（驗證≠授權）。請驗證輸入，並務必在 action 內做擁有者檢查。