對象：正在 Express（Node.js）上維運 API 或應用程式的人。這裡不談攻擊步驟，而是把要替最小框架補上的防禦，整理成正式環境向的實務參考（附優先度的檢查表、分領域對策、自我檢驗）。想看跨框架的全貌，請參閱 各框架資安對策的入口。
附優先度的強化檢查表
先由上而下實施這張表。P0 是前提，P1 是最頻繁的事故源，P2 是持續性的維護。
P0 ── 前提（先做這個）
標頭（helmet）＋停用 x-powered-by／npm 相依套件 CVE 監控／機密從 env、不暴露堆疊
P1 ── 最頻繁的事故源
輸入驗證與注入防護／擁有者範圍的授權
P2 ── 持續維護
速率限制與大小上限／工作階段、cookie、CSRF／SSRF
| 優先 | 對策 | 具體（Express） |
|---|---|---|
| P0 | 安全性標頭 | helmet 式：CSP/HSTS/X-Content-Type 等。停用 x-powered-by |
| P0 | npm 相依套件 CVE | 用 npm audit/osv-scanner 監控；以實際執行版本判定、迅速修補 |
| P0 | 機密與錯誤 | 機密從環境變數取得。正式環境不對外暴露堆疊追蹤 |
| P1 | 輸入驗證 | 驗證/淨化輸入（型別/範圍/允許值）。主體大小上限 |
| P1 | 注入 | DB 查詢綁定。注意 NoSQL 運算子注入（$）。別把輸入傳給 eval |
| P1 | 授權 | 驗證＋在每條路由做擁有者範圍的授權。JWT：驗證簽章、固定 alg |
| P2 | 速率限制 | 對登入/API 設嘗試/流量上限。抑制暴力破解、濫用、DoS |
| P2 | 工作階段/cookie | secure/httpOnly/sameSite。CSRF（cookie 工作階段）。正式環境工作階段儲存 |
| P2 | SSRF | 伺服器端抓取採允許清單＋封鎖內部 IP/中繼資料 |
1. 安全性標頭與削減暴露（P0）
Express **預設不會設定安全性標頭。**先把它們加上去。
- 用 helmet 式中介層加上 CSP、HSTS、X-Content-Type-Options、frameguard 等。
- 停用
x-powered-by以減少框架/版本的暴露。 - 用 安全性標頭檢測 檢查自己的站台。
2. 相依套件（npm）與供應鏈（P0）
- 用
npm audit或 osv-scanner 對相依套件的 CVE 做機器監控，以實際執行版本判定、迅速修補（→ 監控相依套件的 CVE）。 - Node 的相依套件樹龐大，且有供應鏈風險（typosquatting、
postinstall鉤子）。安裝時要審視，並把數量壓下來。 - 讓 Node 保持在受支援的（LTS）版本，別放任 EOL 版本。
3. 輸入驗證與注入（P1）
- 驗證/淨化所有輸入（body、query、params、headers）。設定主體大小上限以抑制 DoS。
- SQL：用佔位符綁定；絕不用字串串接來組查詢（→ 什麼是 SQL 注入）。
- NoSQL：留意經由物件型輸入的運算子注入（
$）（別把原始物件傳進查詢）。 - 別把外部輸入傳給
eval這類危險的求值。
4. 驗證與授權（P1）
常見（危險）
- 沒有授權——「登入＝允許」
- 只依賴中介層的順序/存在
- 原封不動地信任用戶端提供的 ID/旗標
- JWT 簽章未驗證／允許
alg:none
正確
- 驗證之外，還在每條路由做擁有者範圍的授權
- 在靠近資料的地方驗證（別依賴順序）
- 在伺服器端再次驗證（抵抗 ID 掉包）
- JWT 驗證簽章＋固定 alg（拒絕
alg:none）
參閱 什麼是 IDOR · 什麼是 JWT。你可以自己檢視 JWT 的內容（JWT 解碼器）。
5. 速率限制與濫用防護（P2）
- 對登入、API、密碼重設套用嘗試/流量上限，抑制暴力破解、濫用與 DoS。
- 對請求主體與上傳設定大小上限（防止大型負載用盡記憶體等資源）。
6. 工作階段與 cookie（P2）
- 在工作階段 cookie 上設定
secure/httpOnly/sameSite。 - 對 cookie 工作階段的應用程式，加上 CSRF 保護（→ 什麼是 CSRF）。
- 正式環境使用適當的工作階段儲存（預設的記憶體內儲存不適用於正式環境）。在登入時重新產生工作階段。
7. SSRF 與伺服器端抓取（P2）
- 伺服器端抓取使用者提供的 URL 時，應把目標限定在允許清單，並在連線時封鎖對內部 IP／雲端中繼資料的觸達（→ 什麼是 SSRF）。
8. 錯誤處理與正式環境設定（P0〜P2）
- 使用集中式錯誤處理器，並不對外暴露堆疊追蹤。
- 以
NODE_ENV=production執行。在代理之後，正確設定trust proxy，讓 scheme 與用戶端 IP 不被誤判。 - 確實在終端做 TLS/HTTPS。
檢驗：你的 Express 真的強化了嗎
建好不是結束——點檢過才算完成。以下是針對你自己環境的防禦性自我檢查。
標頭與暴露
x-powered-by 已消失。錯誤不會洩漏內部
授權有效
相依套件、速率限制、SSRF
npm audit/osv 是乾淨的、登入速率限制有效，且對外抓取無法觸達內部 IP。本站的觀點：使用精簡框架時，防禦要自己設計
Express 的魅力在於輕巧與自由——那意味著防禦也由你來設計。Rails 與 Laravel 預設會替你守的部分（標頭、CSRF、內建的授權支援），在 Express 上要刻意接進去。重點是把上面的表由上而下逐一處理：設定標頭、驗證輸入、在公開端點寫上授權，並對相依套件監控 CVE。尤其 Node 的相依套件數量龐大，相依套件是否保持最新，很大程度決定會不會發生事故。丟掉「框架會替我守」的假設，把防禦明確地補上去。
接下來讀
- 入口：各框架資安對策 · Next.js 資安對策（同為 Node）
- 實務：監控相依套件的 CVE · 漏洞應變實務
- 名詞：什麼是 IDOR · 什麼是 SSRF · 什麼是 JWT · 什麼是 CSRF
- 工具：安全性標頭檢測 · JWT 解碼器
來源與確認範圍
以下原始資料支持上文的設定、影響範圍或應對措施，連結於2026年10月23日確認。請核對資料中的版本與設定條件。清單優先順序及經驗是本站的整理，不代表全文重新核驗或安全保證。