Storybook 是前端元件開發工作坊，讓團隊在隔離環境中建置、測試與記錄 UI 元件。專案於 2016 年 3 月建立，GitHub 星標累積至 91,255 顆、複製數 10,482 次，貢獻者約 2,806 位，採用 MIT 授權。2026 年 10 月 12 日，官方同步為 8、9、10、11 四條版本線發布修補，處理兩個可導致程式碼注入的開發伺服器漏洞，並改動多項網路相關功能的預設行為。本文依據官方安全公告、版本更新紀錄與 GitHub 公開統計資料整理，說明漏洞成因、修補後的預設行為變化，以及開發團隊需要採取的動作。
Storybook 是什麼？
Storybook 是開源前端元件工作坊，讓開發者在隔離環境中建置、測試與記錄 UI 元件，支援 React、Vue 與 Angular 等主流框架，採用 MIT 授權。
專案的定位是前端工作坊，核心價值在於把元件從完整應用程式中抽離出來，讓開發者單獨檢視每種狀態與互動。這種隔離方式使元件的邊界條件、載入狀態與錯誤處理可以在不啟動完整應用的情況下驗證，也讓設計系統的文件與實際程式碼維持同步。
技術層面以 TypeScript 撰寫，並針對多種前端框架提供整合層。儲存庫標示的主題包含元件、設計系統、文件、測試、React、Vue、Angular、Svelte、Web Components 與 Vite 等，涵蓋目前主流的前端技術選擇。專案另提供可擴充的外掛機制，讓無障礙檢查、視覺回歸測試與互動測試能以附加元件形式接入。
採用規模是此專案最顯著的特徵。官方在儲存庫說明中表示，數千個團隊使用它進行 UI 開發、測試與文件撰寫，累積星標達 91,255 顆，複製數 10,482 次。專案以開放治理方式運作，維護者與貢獻者分布於多個組織，並透過社群頻道與年度會議維持開發者關係。
Storybook 這次修補了哪些漏洞？
本次修補處理兩個開發伺服器漏洞：重大等級者可讓惡意網站未授權修改專案檔案，高風險等級者允許同網段主機竊取權杖並注入程式碼。
第一個漏洞編號 GHSA-f2ph-cmg5-wxc8，嚴重性列為重大。官方說明指出，當受影響版本的開發伺服器執行時，惡意網站可能導致開發者專案中的檔案被未經授權修改。在附加條件成立時，被修改的檔案可能由本機執行環境以開發者的權限執行，最終形成程式碼執行。官方同時聲明，目前未發現實際專案中被利用的證據。
第二個漏洞編號 GHSA-px85-f4q5-jh77，嚴重性列為高風險。官方說明指出，開發伺服器會向任何能載入其 HTML 頁面的客戶端暴露 WebSocket 驗證權杖，因此同一區域網路中的任何主機只要以 IP 位址開啟該應用，即可取得權杖。取得權杖後，攻擊者可透過 WebSocket 對 story 檔案注入程式碼或建立新檔案，在特定條件下可於同網段開發者的機器上執行程式碼。若同時安裝 Vitest 外掛並使用較舊版本，影響程度會進一步提高。
兩份公告都由官方安全團隊協調處理，並在同日發布修補版本。重大漏洞的揭露時間為 9 月 30 日，高風險漏洞的揭露時間為 8 月 19 日，兩者最終併入同一批安全更新一次處理。
為什麼 Storybook 要改變預設網路行為？
官方認為漏洞組合利用的風險足以動搖既有預設值，因此收窄網路存取，改為只監聽 localhost 並限制 iframe 與 postMessage 來源。
官方在公告中說明，由於漏洞的性質特殊，團隊決定改變 Storybook 的預設行為，且範圍包含第 8 與第 9 版，針對多項並非多數使用者工作流程必需的網路功能收緊設定。公告同時提到，這些改動可能被視為破壞性變更，因此為依賴相關功能的團隊提供功能旗標，讓其可以關閉特定的安全更新以維持既有流程。
最直接的變化是監聽範圍。開發伺服器不再綁定機器上的所有網路介面，預設僅綁定 localhost，藉此避免同網段的其他使用者看見該服務。若團隊確實需要在區域網路中分享，可使用命令列選項指定綁定位址，並設定允許的主機清單以通過驗證；官方提醒此舉會觸發警告，需手動確認才會繼續執行。
跨來源互動同樣受到限制。開發模式下的管理介面與預覽介面只接受與自身來源或本機服務之間的通訊，跨網域的 iframe 嵌入在預設狀態下被拒。已建置完成的 Storybook 不受此限，仍可自由嵌入。官方建議需要組合多個 Storybook 的團隊改為使用建置版本。此外，highlight 事件的 API 曾被過度授權，經重新設計後不再能觸發任意事件，Chromatic 的 Visual Tests 外掛需更新至 5.4.1 或之後版本以維持文件連結功能。
開發者應該如何處理這次修補？
先升級至對應版本線的修補版再啟動開發伺服器，分別為 11.0.0-alpha.6、10.6.2、9.1.21 與 8.6.19；無法立即升級者應暫停執行開發伺服器。
處理順序的第一步是升級。官方為四條版本線分別發布修補版本，包含 11.0.0-alpha.6、10.6.2、9.1.21 與 8.6.19，並明確要求在下一次執行 storybook dev 之前完成升級。若團隊短期內無法升級，官方建議直接停止執行受影響的開發伺服器，直到可以套用修正。
接著需要檢視既有工作流程是否依賴已改動的功能。若團隊曾把開發中的 Storybook 嵌入另一個網頁應用，或依賴跨來源的訊息傳遞更新 story 參數，這些用法在升級後可能失效。官方為此提供 security.insecureRemoteIframeEmbed 與 security.insecurePreviewMessaging 等功能旗標，但公告建議優先改用建置版本或本機執行等較安全的方式，把旗標保留給確實無法調整的少數情境。
測試相關設定亦有兩處需要確認。Vitest 外掛在瀏覽器模式下不再允許寫入檔案或執行其他程序，若測試流程原本依賴這兩項能力，需在設定中手動重新啟用。saveStoryRequest 事件的輸入驗證亦已收緊，外掛與介面只能寫入序列化參數與 story 標題，若團隊自行開發會代為寫入檔案的外掛，官方建議直接聯繫維護者取得安全實作建議。
Storybook 的專案數據與維護狀況如何？
專案累積 91,255 顆星標、10,482 次複製與 88,257 次提交，貢獻者約 2,806 位，最近一次推送為 2026 年 10 月 12 日。
維護強度是此專案的另一項特徵。儲存庫累積 88,257 次提交與約 2,806 位貢獻者，最近一次推送時間為 2026 年 10 月 12 日，與本文整理時間相隔一日。貢獻者活躍度圖表顯示，每週提交次數在觀察期間維持穩定，並在 8 月中旬出現明顯高峰，反映版本開發與安全稽核期間的集中投入。
版本策略則採用多線並行。官方同時維護第 8、9、10 與 11 四條線，其中第 11 版處於 alpha 階段，其餘為穩定線。這種做法讓仍在使用較舊主版本的團隊可以在不進行大版本遷移的前提下取得安全修正，代價是維護者需要同步處理多條分支的修補與發布。儲存庫目前待處理議題約 1,885 項，數量與其龐大的生態規模相符。
Storybook 在同類工具中的定位為何？
與單純的元件預覽工具相比，Storybook 同時涵蓋文件、無障礙檢查與視覺回歸測試，並以框架無關的外掛架構支援跨團隊協作，轉換成本較高。
現階段的前端生態中，元件可視化並非只有一種做法，部分框架提供官方或社群維護的獨立預覽工具，也有一些團隊自行以最小化的展示頁面取代。這些方案的共同優勢是設定成本較低，適合元件數量有限或技術棧單一的專案。
Storybook 的差異在於整合範圍。它同時涵蓋元件文件、無障礙檢查、互動測試與視覺回歸測試，並以框架無關的外掛架構讓不同技術棧的團隊共用同一套流程。這種設計使其在中大型專案與跨團隊情境下具備優勢，但也代表導入後的文件與 stories 會形成一定的轉換成本，較難在專案中途更換。
值得留意的是，本次修補改變了部分預設行為，而這些行為過去並未被視為需要調整的風險來源。對於把元件工作坊納入 CI 流程或內部部署的團隊，這代表安全邊界需要重新檢視。官方以功能旗標保留回溯能力的做法，短期內降低了升級阻力，但長期而言，收窄預設權限的方向與近年開發工具供應鏈強化的趨勢一致。
出處連結有哪些？
本文資訊整理自 Storybook 官方儲存庫的安全公告與版本更新紀錄，完整公告內容、修補版本清單與功能旗標說明可由下列來源查證。
官方儲存庫位於 https://github.com/storybookjs/storybook，內含完整原始碼、貢獻指南與授權文件。兩份安全公告分別為 https://github.com/storybookjs/storybook/security/advisories/GHSA-f2ph-cmg5-wxc8 與 https://github.com/storybookjs/storybook/security/advisories/GHSA-px85-f4q5-jh77，內容涵蓋受影響範圍、建議動作與揭露時程。版本更新紀錄見 https://github.com/storybookjs/storybook/releases，官方網站為 https://storybook.js.org，其中提供安裝說明與文件。
常見問題有哪些？
Storybook 只在本機執行，為什麼仍有安全風險？
開發伺服器雖然執行於本機，但會開啟網路連接埠並提供網頁介面，因此瀏覽器中的惡意網站或同一區域網路的其他主機都可能與其通訊。當這些通訊缺乏來源驗證與權杖保護時，就有機會演變成檔案修改甚至程式碼執行。本次修補的核心正是收窄這些連線的可信任範圍。
升級後既有工作流程失效該如何處理？
先確認失效的是 iframe 嵌入、跨來源訊息傳遞，還是 Vitest 瀏覽器模式的檔案寫入與程序執行能力。前三者可透過官方提供的功能旗標暫時還原，建議同時評估改用建置版本或本機執行的替代方案。若為自行開發的外掛，官方建議直接聯繫維護者取得安全實作建議。
使用已建置的 Storybook 會受影響嗎？
不會。官方公告明確指出，執行或瀏覽已建置版本的 Storybook 不受影響，建置版本仍可自由嵌入其他網頁，也繼續接受來自未知來源的訊息傳遞。受影響的情境僅限於執行開發伺服器，且該伺服器可被外部來源存取的情況。
總結：Storybook 使用者該如何應對？
建議先升級至對應版本線的修補版，再重新檢視團隊是否依賴已改動的網路功能；無法立即升級者應停止執行開發伺服器，並避免在不受信任的區域網路中開啟。
本次事件的重點不只是一次版本更新，而是開發工具安全邊界的重新界定。官方為 8、9、10 與 11 四條版本線同步發布修補，處理一個重大與一個高風險漏洞，並主動收窄開發伺服器的預設網路行為，包含僅監聽 localhost、限制 iframe 嵌入來源，以及收緊訊息傳遞與檔案寫入的驗證。
對日常使用者而言，動作相對明確：升級至對應版本線的修補版，並避免在不受信任的網路環境中啟動開發伺服器。對把 Storybook 納入內部部署或 CI 流程的團隊，則需要進一步確認自動化流程是否依賴被限制的跨來源功能，並評估是否改用建置版本。若團隊自行開發會寫入檔案的外掛，輸入驗證的收緊代表相關實作需要重新測試。