題干與適用場景
請評審一個瀏覽器存取多租戶 Web 應用程式的架構。你如何畫出系統邊界與資料流，辨識資產與威脅來源，區分目標、實作與外部威脅，並把回應寫成可驗證的安全不變量？
W3C Security Interest Group 於 2026 年 5 月 26 日發布 Threat Model for the Web Group Note Draft。該草案是資訊性、非規範性文件，用於新 Web 規範的安全評審，並以瀏覽器、DNS、Web Server、使用者與網路營運者等簡化元件說明威脅模型。面試重點是方法與證據鏈，不是背誦草案結論。
面試官考察點
面試官會看你能否先畫出系統與資料流，再討論資產、利害關係人與威脅來源；能否區分威脅、弱點、影響與回應；能否把安全目標寫成可檢查的不變量；能否持續更新模型並把結論放入設計與評審文件。優秀答案還會說明模型的抽象邊界、未建模攻擊者假設，以及如何處理規範外依賴風險。
回答前需要釐清的問題
- 評審對象是瀏覽器平台、某個 Web 應用程式，還是兩者之間的新 Web API？
- 要保護的資產包括憑證、使用者資料、程式碼、工作階段、網路中繼資料還是可用性？
- 資料流是否包含第三方腳本、CDN、DNS、身分提供者與跨站請求？
- 威脅模型用於設計初審、發布前安全審查，還是線上變更評估？
- 哪些依賴與外部威脅明確在範圍外，誰負責接續評審？
30 秒回答框架
「我先用一張帶唯一 ID 的資料流圖定義邊界，列出元件、儲存、流與利害關係人，再逐項列出資產與威脅來源。對每個威脅記錄前置條件、受影響資料流、影響、既有控制與殘餘風險，並歸類為規範目標、實作風險或外部依賴。然後將回應寫成安全不變量與驗證證據，分配負責人與更新觸發器。模型應與系統設計同步開始，在正式安全評審前形成可稽核版本。」
分步驟深入解答
1. 先畫清系統邊界
從最小可用情境開始，標出瀏覽器程序與儲存、DNS 服務、Web Server、使用者、網站管理員與網路管理員。每個元件使用唯一短 ID，並配套文字字典解釋職責與信任邊界。若評審的是新 API，再把 API 的輸入、輸出、權限與依賴嵌入這張圖，不要另畫孤立圖。
2. 列出資產與利害關係人
資產可以是憑證、工作階段令牌、使用者內容、腳本、來源身分、DNS 解析結果、可用性與隱私中繼資料。利害關係人包括終端使用者、網站營運者、網路營運者、應用程式提供者與公共部門。把「誰受影響」與「誰可能攻擊」分開，避免只把使用者當成需要保護的物件。
3. 記錄威脅來源與高層威脅
對每項威脅說明來源、目標資產、攻擊路徑與影響。可以用仿冒、竄改、資訊洩露、阻斷服務、權限繞過等類別組織清單，但必須回到具體資料流。將威脅分成規範希望處理的目標威脅、實作者已知但不適合寫入規範限制的實作威脅，以及依賴或部署環境造成的外部威脅。
4. 把回應寫成不變量
安全不變量是系統在所有允許執行中都應保持的條件，例如「跨來源回應不會把未授權憑證交給呼叫方」或「腳本來源與權限邊界不能被回應重新導向繞過」。每條不變量關聯控制、測試、日誌或稽核證據，並註明是規範保證、實作保證還是部署前提。
component/flow -> asset -> threat source -> impact
-> invariant -> control -> evidence -> owner5. 處理依賴與外部威脅
Web 依賴 DNS、TLS、HTTP、憑證、路由與腳本等多層協定。模型不應假裝涵蓋所有依賴，而要列出依賴威脅、繼承的安全假設與交接點。例如 DNS 欺騙、資源竄改或網路監視可能超出目前規範範圍，但必須引用相關技術的威脅模型，並記錄採用的前提。
6. 讓模型與生命週期同步
威脅模型應在使用情境、解釋文件與設計初稿階段開始，隨功能與資料流變化持續更新；正式橫向安全評審前應準備完成。變更觸發器包括新增入口、權限變化、新依賴、瀏覽器程序邊界變化與現實事件。版本化模型、評審記錄與差異說明，才能知道風險是新增、關閉還是重新分類。
7. 證明回應有效
設計評審階段可用單元測試、整合測試、瀏覽器安全測試、攻擊模擬、設定檢查與日誌查詢驗證回應。對無法測試的不變量，給出可稽核理由、殘餘風險與接受者。不要把「沒有發現漏洞」寫成證明；要說明觀察範圍、測試條件與未涵蓋區域。
高品質示範回答
我會先定義最小瀏覽器存取情境，用唯一 ID 標出瀏覽器程序及其儲存、DNS、Web Server、使用者與網路營運者，並為每條資料流寫字典。接著列出憑證、工作階段、使用者內容、腳本、解析結果與隱私中繼資料等資產，再記錄每個威脅的來源、前置條件、受影響資料流與影響。威脅清單區分規範目標、實作風險與外部依賴，避免把部署前提偽裝成規範保證。每個回應都寫成可檢查的不變量，綁定控制、測試或稽核證據與負責人。模型從使用情境與設計初稿開始，新增入口、依賴或權限變化時更新，正式安全評審前凍結一個帶版本的模型。對 DNS、TLS、腳本與路由等外部依賴，我會明確引用其模型或安全假設，並保留殘餘風險。這樣評審結果既能指導設計，也能在後續變更中重用與追蹤。
常見錯誤
- 只列弱點名稱 → 沒有系統邊界與資料流 → 先畫元件、流與信任邊界。
- 把威脅、弱點與影響混為一談 → 回應無法驗證 → 逐項記錄來源、前置條件、影響與控制。
- 把所有風險都塞進目前規範 → 範圍失真 → 區分目標、實作與外部威脅並標示依賴。
- 只在發布前做一次模型 → 設計變化未被涵蓋 → 從使用情境開始並設定更新觸發器。
- 把安全目標寫成口號 → 沒有驗收證據 → 改寫為不變量並綁定測試、日誌或稽核。
- 忽略殘餘風險 → 決策不可追蹤 → 寫明未涵蓋區域、接受者與後續行動。
追問及應對
為什麼不先列舉所有攻擊者？
先定義元件、資產與資料流可減少範圍漂移。攻擊者模型仍可補充，但不能讓對攻擊者動機的猜測取代對系統邊界與可驗證控制的分析。
如何處理第三方腳本？
把腳本來源、載入流、可存取憑證與執行權限畫入模型，定義來源限制、隔離與監控不變量；若由供應商負責，記錄交接證據與殘餘風險。
什麼時候把外部依賴升級為目前專案風險？
當依賴的安全假設直接影響目前資產或不變量，或專案無法驗證依賴承諾時，就應列為目前風險並指定緩解或接受者，不要留在註腳。
安全評審發現模型過於複雜怎麼辦？
保留涵蓋主要風險的最小圖，拆出協定或部署層的子模型，並透過元件 ID、流 ID 與連結保持可追溯；複雜度不能靠刪除關鍵邊界降低。
如何向產品負責人解釋殘餘風險？
用受影響資產、可能路徑、目前控制、測試證據與業務影響說明，給出選項、成本、期限與明確接受者，不使用「絕對安全」或不可驗證的機率承諾。