如何評估團隊瀏覽器：實用檢查清單

先定義決策需求，再看價格頁

有效的評估從工作需求開始，而不是先列廠商名單。請寫下：

• 獲授權的工作流程，以及允許這些操作的系統。
• 人員數、已儲存設定檔數、同步設定檔數與同時執行的瀏覽器工作階段數。
• 需要支援的作業系統與處理器架構。
• 必要的瀏覽器引擎、擴充功能、代理伺服器、身分識別提供者與自動化用戶端。
• 資料落地地區、保留、匯出、刪除與稽核義務。
• 預期復原時間與可接受的資料損失。
• 操作人員與管理員的無障礙需求。
• 預算、計費週期、支援範圍與退出條件。
• 團隊禁止、產品也不得協助執行的工作流程。

請分別計算不同資源。方案若包含 500 個已儲存設定檔、100 個雲端同步設定檔、5 個使用者席次與 10 個同時執行的工作階段，並不代表團隊能同時使用 500 個工作階段。每個限制都應換算成實際工作會消耗的單位。

接著列出不能妥協的必要條件，常見項目包括：

1. 受支援且及時更新的瀏覽器版本。
2. 不會無聲地損毀設定檔，也不允許多方同時寫入同一份可變狀態。
3. 每人使用獨立身分，存取權可撤銷並遵循最小權限。
4. 一般日誌與自動化輸出不含原始機密資訊。
5. 可用的稽核證據。
6. 經測試的還原與退出流程。
7. 合法、獲授權，且符合適用服務條款的使用方式。

必要條件未通過時，不要用其他項目的高分把它平均掉。再精美的介面，也無法補償未經驗證的更新機制，或會遺失狀態的還原流程。

使用簡單的證據分級

每個檢查項目都應記錄結果，以及目前取得的最有力證據。

結果

• 通過：在明確定義的測試環境中，已證明符合要求。
• 疑慮：行為不符合要求，或帶來重大取捨。
• 未驗證：證據缺失、無法取得、已過時，或含糊到不足以判斷。
• 不適用：該要求確實不適用於目前工作流程，並已記錄原因。

證據

1. 公開宣稱：行銷或業務文案。
2. 技術文件：有版本的產品、安全、API 或支援文件。
3. 觀察示範：廠商依你的情境進行即時示範。
4. 受控試用：團隊以可丟棄的資料重現行為，記錄版本與結果。
5. 獨立或合約證據：涵蓋該要求、範圍明確的評估報告、簽署承諾或支援條款。

證據等級較高，不代表在每種情況下都更合用。獨立報告可能不包含桌面瀏覽器，受控試用卻可能直接測到它。每份證據都要記錄範圍、日期、版本與限制。

1. 產品狀態與宣稱範圍

• □ 每個必要平台與架構，是否都有真正可安裝的版本？
• □ 廠商能否提供目前的應用程式版本、瀏覽器版本與發布日期？
• □ Beta、預覽、實驗性與正式推出的功能，是否分別標示？
• □ 文件與實際試用中的限制、行為是否一致？
• □ 安全、可用性、加密與效能宣稱，是否對應到明確元件與證據？
• □ 是否公布已知限制、不支援的工作流程與終止支援規則？
• □ 廠商是否避免保證隱形、帳號永久存活或必定能存取第三方服務？

請保留評估當天的安裝程式、版本畫面、版本說明與相關文件。沒有穩定參考資料的業務答覆，仍屬宣稱，不能算已驗證的行為。

2. 設定檔隔離與完整性

先確認產品所說的「設定檔」是什麼。它可能是持續保留的瀏覽器資料目錄、暫時性的瀏覽器情境、同步封存檔、遠端工作階段，或一組設定。這些概念並不相同。

Chromium 文件將使用者資料目錄定義為儲存使用者資料的位置，並說明如何選擇自訂目錄，也指出執行中的兩個執行個體無法共用同一目錄的情況。可以從上游使用者資料目錄文件開始了解，但仍須要求產品本身的證據。

• □ 每個持續性設定檔是否有明確的儲存與程序邊界？
• □ 產品是否阻止兩個寫入者同時開啟同一份可變設定檔狀態？
• □ Cookie、儲存資料、快取、歷史紀錄、擴充功能、下載、權限與偏好設定，是否依文件說明隔離？
• □ 暫時工作階段與持續性設定檔是否有不同標示？
• □ 乾淨啟動時，是否只使用預期的設定檔資料？
• □ 重新啟動後，是否確實保留產品承諾保留的狀態？
• □ 擴充功能的權限與安裝來源是否受控？
• □ 匯入設定檔是否被視為不可信輸入，並在使用前驗證？
• □ 損毀或不相容的設定檔能否隔離處理，而不覆寫已知正常的副本？

試用證據應包含跨設定檔測試。在設定檔 A 放入無害標記，確認設定檔 B 沒有該標記，重新啟動兩者後再檢查，並在應用程式更新後重做。使用可丟棄的帳號與合成資料。

3. 瀏覽器更新時效、沙箱與更新機制

瀏覽器是攸關安全的軟體元件，需要持續維護。自2026年9月8日推出的 Chrome 153 起，Chrome Stable 改為每兩週發布一個新版本。這個發布週期並不直接規定各供應商的具體服務承諾，但說明了為什麼僅有「以 Chromium 為基礎」的說法還不夠，還需要版本與更新方面的證據。

• □ 能否將產品的瀏覽器版本對應到確切的上游版本？
• □ 是否公布採用上游安全更新的目標或歷史紀錄？
• □ 誰負責監控上游發布與緊急修正？
• □ 應用程式及瀏覽器更新是否有簽署與驗證，且不只依靠下載連線的安全性？
• □ 能否驗證成品摘要、發布來源證明，或等效的保管鏈？
• □ 更新是否分階段推出、受監控，且可以暫停？
• □ 回復舊版時，是否避免回到依目前安全政策已不安全的版本？
• □ 設定檔結構轉換是否涵蓋受支援的升級與降級路徑測試？
• □ 正常操作是否維持瀏覽器沙箱啟用？
• □ 廠商能否說明任何未使用沙箱或具高權限的程序，以及其必要性？

Chromium 將沙箱描述為限制不可信程式碼的邊界，並對沙箱內程式碼及控制端套用最小權限。閱讀 Chromium 沙箱設計後，請廠商展示實際正式環境設定。「使用 Chromium」並不能證明所有上游防護仍然啟用。

評估更新完整性時，The Update Framework 是有用的參考，因為它明確處理儲存庫及簽署金鑰遭入侵的情況。SLSA 來源證明則定義可驗證的成品資訊，說明成品在何處、何時與如何產生。廠商不一定要採用這些專案，但應解釋其設計如何處理成品身分、金鑰外洩、降版攻擊、凍結攻擊與建置來源證明。

4. 身分、裝置與最小權限

NIST SP 800-53 第 5 版將控制措施分為存取控制、稽核、身分驗證、應變規劃、事件回應與供應鏈風險等類別。請把這些類別當作提問依據，而不是把「符合框架」當成已實作的證明。

• □ 每個人是否有獨立身分，而不是共用團隊登入？
• □ 管理員及其他敏感角色是否能使用並被要求啟用多因素驗證？
• □ 風險需求較高時，是否支援更強且能抵抗網路釣魚的驗證方式？
• □ 若需要與身分識別提供者聯合登入，能否做到且不繞過產品授權？
• □ 角色是否足夠細緻，能區分檢視、啟動、編輯、分享、匯出、刪除、帳務與管理？
• □ 能否把存取權限於特定組織、工作區、資料夾或明確的設定檔集合？
• □ 能否及時撤銷裝置、工作階段、使用者、服務憑證或邀請？
• □ 服務帳號是否有自己的身分、到期時間、範圍與速率限制？
• □ 權限變更與授權失敗是否出現在稽核紀錄中？
• □ 人員離職時，能否不更改共用密碼就移除其存取權？

現行驗證術語與保證等級指引，可參考於 2025 年 7 月 31 日定稿的 NIST SP 800-63B-4。請確認廠商的驗證宣稱涵蓋哪些部分：網站登入、桌面解鎖、本機 API、雲端 API、復原與支援人員存取，可能採用不同機制。

5. 敏感資料與信任邊界

畫出產品的資料流程，標示桌面管理程式、瀏覽器程序、本機服務、雲端控制層、同步儲存空間、更新程式、當機回報工具、支援工具與第三方整合。每個邊界都要問：什麼資料會跨過去？為什麼？

• □ 哪些設定檔內容預設留在本機？
• □ 啟用同步時，哪些中繼資料與敏感內容會上傳？
• □ 在哪裡加密？哪些對象能取得解密金鑰？
• □ 本機金鑰如何保護、備份、輪替與復原？
• □ 組織管理員、廠商支援人員、基礎設施維運人員與自動化用戶端能讀取什麼？
• □ 一般介面、日誌、遙測、API 與代理程式輸出，是否排除 Cookie、密碼、代理憑證、雙因素驗證機密與加密金鑰？
• □ 當機回報與診斷資料是否可預覽、會遮蔽敏感資訊、尊重同意設定，且有保留期限？
• □ 支援人員能否不索取原始設定檔封存檔或憑證就處理問題？
• □ 匯入的擴充功能、封存檔、瀏覽器下載與更新中繼資料，是否視為不可信內容？
• □ 刪除的定義是否涵蓋本機副本、雲端物件、備份、日誌與支援資料？

「已加密」不是完整答案。請記錄資料類別、位置、加密邊界、金鑰持有人、復原方式，以及何時會存在明文。

6. 協作與可稽核性

• □ 分派與交接時，設定檔的負責人是否始終清楚？
• □ 產品能否阻止同時編輯，或清楚處理衝突？
• □ 邀請、角色變更、啟動、停止、分享、匯出、刪除、自動化呼叫與復原操作，是否都有紀錄？
• □ 每個事件是否標示人員、受委派工作、資源、時間、決策與結果？
• □ 重要設定變更是否記錄前後值，並遮蔽機密資訊？
• □ 時鐘、時區、事件順序與請求識別碼是否明確？
• □ 稽核存取權、匯出格式、保留與刪除控制是否有文件說明？
• □ 管理員是否能修改或抹除用來審查自身行為的紀錄？
• □ 團隊能否將日誌匯出到自己的監控或調查系統？
• □ 稽核目的地無法使用時，日誌會繼續記錄、安全暫存，還是停止相關操作以確保安全？

OWASP 日誌指引建議記錄授權失敗與高風險操作，保留時間、位置、人物與事件資訊，同時控制日誌存取並避免包含技術機密。請用產品實際匯出的事件驗證，而不是只看安全頁面上的截圖。

7. 復原、中斷與退出

未測試還原的備份宣稱仍不完整。NIST 網路安全框架 2.0涵蓋建立、保護、維護與測試備份，以及驗證還原資源與還原後系統的成果。

• □ 能否在遵守設定檔鎖定規則的前提下，建立一致的備份？
• □ 本機與同步版本是否可識別並有明確順序？
• □ 操作人員能否還原選定版本，而不破壞目前副本？
• □ 恢復正常使用前，是否驗證還原資料與瀏覽器相容性？
• □ 強制終止瀏覽器程序、斷網、磁碟空間用盡、上傳中斷或應用程式當機時，會發生什麼？
• □ 修復失敗時，是否保護最後已知正常的版本？
• □ 能否移除已撤銷或遺失的裝置，而不失去唯一復原途徑？
• □ 復原金鑰或代碼是否兼顧避免意外遺失與防止管理員無限制存取？
• □ 團隊能否以有文件說明的格式匯出資料，並在取消服務前驗證匯出內容？
• □ 是否提供受支援的刪除與關閉帳號流程，清楚說明殘留資料的保留情況？

除非廠商與團隊變更流程明確允許正式環境演練，否則復原測試只能使用可丟棄的試用資料。記錄復原時間、遺失狀態、手動步驟、警告與產品版本。單一小型設定檔的成功示範，不足以證明正式環境規模下的效能與完整性。

8. 自動化與開發者控制

• □ 產品是否提供有版本的領域操作，而不是無限制的檔案系統或程序存取？
• □ API、CLI、SDK、Playwright、CDP、WebDriver、Webhook 與代理程式能力，是否分別有文件說明？
• □ 是否有精確的瀏覽器與用戶端相容性矩陣？
• □ 憑證能否依租戶、設定檔、操作、使用對象、到期時間、速率與費用限制？
• □ 破壞性、大量、對外可見、涉及機密或會產生費用的操作，是否需要更嚴格的政策或核准？
• □ 預覽是否綁定到實際將執行的確切請求？
• □ 會變更狀態的命令是否具冪等性，或明確標示結果未知？
• □ 長時間操作能否取消並安全繼續？
• □ 撤銷權限是否會在工作執行途中生效？
• □ 自動化決策能否在與人工操作相同的稽核紀錄中追溯責任？
• □ 一般自動化輸出能否在不回傳原始工作階段狀態的情況下，仍然實用？
• □ 錯誤訊息是否足以協助復原，且不洩漏機密？

也要測試拒絕路徑。唯讀權杖應無法啟動設定檔；限於特定設定檔的權杖應無法存取其他資料夾；過期憑證不應悄悄更新成更廣泛的權限。代理程式也不應能透過改寫請求，把被拒絕的呼叫變成管理員核准。

9. 操作體驗與無障礙使用

• □ 鍵盤使用者能否到達、操作並離開每個控制項、對話框、表格、選單與設定檔操作？
• □ 導覽、錯誤與模態視窗變更後，焦點是否可見且順序合理？
• □ 標籤、錯誤、狀態變化與破壞性操作確認，是否能搭配螢幕閱讀器使用？
• □ 放大畫面或文字後，介面是否仍可操作？
• □ 顏色、動態效果與時間限制是否可調整，或不是完成操作的必要條件？
• □ 操作人員能否不只靠顏色，就分辨目前組織、設定檔、代理、環境與風險狀態？
• □ 大量操作是否可供檢查，而不強迫使用者操作難以使用的密集表格？
• □ 原生平台行為、通知、檔案選擇器、憑證提示與更新對話框是否一致可靠？

WCAG 2.2 提供可測試的網頁內容準則，包含鍵盤操作、焦點順序與可見性、目標尺寸、錯誤識別與無障礙驗證。桌面產品可能同時包含原生與網頁介面，因此應在每個支援的作業系統上，結合相關標準檢查與輔助科技測試。

10. 商務與營運適用性

• □ 席次、已儲存設定檔、同步設定檔、儲存容量、流量、同時執行的工作階段、API 速率、自動化工作程序與支援等級，是否分別且清楚計價？
• □ 哪些限制會直接停止操作，哪些產生超額費用，哪些適用合理使用條款？
• □ 帳務或容量是否可能在未經管理員核准下變更？
• □ 支援的代理通訊協定、驗證方式、擴充功能與網路環境，是否有文件說明？
• □ 支援政策是否涵蓋瀏覽器更新事故、設定檔損毀、還原失敗、安全通報與帳號復原？
• □ 服務狀態、事故溝通與升級處理管道，是否確實運作且有人監控？
• □ 合約是否定義資料返還、刪除、價格變動、暫停與終止？
• □ 能否在退出服務時，保留證明安全移轉所需的證據？

請依尖峰同時作業量、預期同步狀態、自動化用量與支援需求計算費用，並記錄稅金、年約承諾、超額費用與移轉人力。不要只比較價格頁面上最大的設定檔數字。

受控試用計畫

使用測試帳號、合成憑證與專為評估建立的設定檔，不要為了讓試用更像真實情境，就匯入正式環境 Cookie。

1. 記錄環境。 記下應用程式與瀏覽器版本、作業系統、硬體、網路、代理類型、擴充功能、帳號方案與測試日期。
2. 建立兩種角色與數個設定檔。 包含管理員、權限受限的操作人員、不同資料夾，以及至少一個該操作人員不得存取的設定檔。
3. 執行正常流程。 啟動、使用、停止、交接並重新啟動設定檔，記錄預期與實際狀態。
4. 測試拒絕行為。 用受限身分嘗試存取範圍外設定檔、匯出、變更角色與執行自動化命令。
5. 測試中斷。 使用可丟棄資料，以廠商支援或其他安全方法中斷瀏覽器停止或同步步驟，驗證復原路徑。
6. 還原並比較。 將已知快照還原成新副本，驗證完整性，並保留目前副本直到驗收完成。
7. 撤銷存取權。 移除使用者、裝置、工作階段與服務憑證，確認介面及 API 都拒絕存取，並檢查稽核事件。
8. 檢查可攜性。 匯出允許的資料，檢查文件所述格式；若支援，匯入可丟棄的目的地，並找出未包含的內容。
9. 檢查無障礙使用。 在每個必要平台上，以鍵盤與相關輔助科技完成核心工作。
10. 核對費用與宣稱。 將觀察到的資源用量與支援回覆，對照提案及合約。

決策紀錄範本

要求	優先程度	結果	證據與日期	限制或風險	負責人與下一步
範例：操作人員無法匯出工作階段狀態	必要條件	通過	受控試用，版本 X，YYYY-MM-DD	只測試 API，未測試 CLI	安全負責人測試 CLI

結束評估時，請明確列出四份清單：

• 已有充分證據支持通過的必要條件。
• 由具名負責人接受、並訂有複查日期的疑慮。
• 仍未驗證的項目。
• 會觸發重新評估的條件，例如新瀏覽器引擎、身分識別提供者、更新機制、計價方式或設定檔格式。

常見警訊

遇到下列情況，請暫停決策：

• 無法確認瀏覽器版本。
• 正常使用必須停用沙箱。
• 管理員與自動化共用永久憑證。
• 團隊交接依賴分享原始 Cookie 或密碼。
• API 能匯出介面宣稱會保護的機密。
• 稽核事件缺少操作人員，或無法匯出。
• 所謂「備份」只代表有雲端副本，卻未示範過還原。
• 廠商無法解釋寫入中斷或同時存取設定檔時的行為。
• 重要流程無法無障礙操作，也沒有替代方式。
• 安全通報要求透過一般電子郵件傳送機密。
• 產品承諾無法被偵測、保證帳號可用，或規避平台執法。

「未驗證」不是指控，而是準確描述證據仍不足。請保留這個狀態，直到廠商提供證據、團隊完成測試，或決策負責人明確接受風險。