從 45 個 npm 漏洞到零風險:為何不應在靜態網站上盲目執行 npm audit fix --force
· 閱讀時間約 7 分鐘
每一位現代前端開發者都曾體驗過腎上腺素飆升的瞬間:當你在一個乾淨整潔的文件或部落格程式碼庫中執行 npm audit 時,終端機突然噴湧出一片觸目驚心的鮮紅警告:
45 vulnerabilities (15 moderate, 15 high, 15 critical)
To address all issues (including breaking changes), run:
npm audit fix --force
看到諸如 Critical (嚴重)、Remote Code Execution (遠端代碼執行/RCE) 和 Prototype Pollution (原型鏈污染) 這樣的高危詞彙,人類的第一反應往往是毫不猶豫地敲下 npm audit fix --force,試圖讓這些刺眼的紅字立刻消失。
然而,在基於 靜態網站產生器 (SSG)(例如部署在 GitHub Pages 或 AWS S3 上的 Docusaurus、Next.js 或 Hugo)的世界裡,這樣做往往是一個嚴重的工程誤判——它不僅無法真正提升你的安全水位,反而會破壞生產環境的建構流程。
在本文中,我們將深入剖析 靜態網站的威脅模型 (Threat Model),揭示打包編譯期漏洞與線上伺服端漏洞的本質差異,並分享一套經生產檢驗的 4 層靜態安全加固藍圖,保護真正核心的資產:你的機密憑證、訪客隱私以及程式碼庫完整性。
