前端面試：如何安全地為瀏覽器代理暴露 WebMCP 工具？
題目
電商結帳頁準備試用 WebMCP，讓瀏覽器代理替使用者篩選商品並填寫表單。你如何定義工具、限制權限、保留使用者控制，並驗證代理不會誤呼叫高風險動作？
場景與適用邊界
WebMCP 是提議中的 Web 標準，Chrome 文件描述了宣告式 HTML 表單工具和命令式 JavaScript 工具；Chrome 149 開始提供 origin trial。題目討論瀏覽器分頁內、有人在環的漸進增強，不把 WebMCP 當成已穩定、可在無瀏覽器上下文執行的後端協定，也不把它當成取代伺服器授權的安全邊界。
回答前可以確認：哪些動作只是篩選和填充，哪些動作會下單或扣款？工具只對頂層頁面可見，還是要暴露給跨來源 iframe？使用者是否必須在最終提交前再次確認？如何處理代理不支援 WebMCP 或 origin trial 結束？
面試官考察點
考察你能否把代理可呼叫性設計成前端契約：工具描述和輸入 schema 足夠明確，呼叫仍經過現有登入、CSRF、業務授權和使用者確認，跨來源暴露遵循最小權限，並用評估集驗證呼叫選擇、參數和結果。
30 秒回答框架
先把使用者旅程拆成唯讀、可逆和不可逆動作；唯讀篩選可用宣告式或命令式工具，提交訂單保留伺服器授權和明確確認。工具 schema 只暴露必要欄位，預設限制在目前頁面和來源，跨來源 iframe 需要明確 Permissions Policy。發布前用真實任務評估工具選擇、參數驗證、錯誤處理和拒絕路徑，並保留 DOM 操作降級。
分步深入解答
- 劃分風險：
search、filter、fill屬於低風險或可逆動作；place-order、pay、修改地址屬於高影響動作，不能因代理取得工具就自動執行。 - 設計契約：每個工具有穩定名稱、面向代理的描述、JSON 輸入 schema 和結構化結果；列舉、範圍、幣別、庫存版本等約束在前端和伺服器端都驗證。
- 重用業務邏輯：工具回呼呼叫現有表單狀態和領域函式，不複製一套繞過使用者介面的請求；執行前檢查登入、購物車版本、CSRF、價格和庫存。
- 權限邊界：預設只在頂層視窗和同源上下文暴露；跨來源 iframe 只有在
Permissions-Policy和 iframeallow明確允許時才共享工具，工具不得返回不必要的個人資料。 - 使用者控制：篩選和填充可以先執行並展示變更；下單、付款、刪除等動作要求頁面內確認和可見摘要，工具結果說明是否完成、等待確認或被拒絕。
- 漸進發布：在本地 flag 或 origin trial 中先對內部帳號啟用，提供能力偵測、無 WebMCP 時的正常 UI 和 DOM 自動化降級；記錄工具版本、呼叫結果和拒絕原因。
- 評估與監控：建立任務集，測工具選擇準確率、參數合法率、完成率、誤呼叫率、拒絕正確率和使用者確認覆蓋率；對高風險工具設定零誤呼叫門檻，發現異常立即撤銷註冊。
高品質示範回答
我會先把結帳旅程拆成篩選、填充和提交三個階段。篩選與填充是可逆動作，可以使用 WebMCP 工具改善代理定位；下單和付款仍由現有伺服器授權、價格庫存驗證和頁面確認決定。WebMCP 是實驗性提議，Chrome 149 的 origin trial 只適合受控驗證，不能取代後端權限。
工具只宣告完成目前使用者旅程所需的最小欄位，並在回呼中重用現有表單和領域邏輯。輸入 schema 限制商品 ID、數量和地址格式，伺服器再次驗證登入、CSRF、庫存、價格和訂單冪等鍵。預設只暴露給頂層頁面和同源代理；若必須支援跨來源 iframe，就同時設定權限策略和 iframe allow，不把整套帳戶資料返回給工具。
const controller = new AbortController();
document.modelContext?.registerTool({
name: "cart_set_quantity",
description: "Set the quantity of one visible cart item; never submits an order.",
inputSchema: {
type: "object",
properties: {
itemId: { type: "string", minLength: 1 },
quantity: { type: "integer", minimum: 1, maximum: 10 }
},
required: ["itemId", "quantity"]
},
async execute({ itemId, quantity }) {
const result = await setVisibleCartQuantity(itemId, quantity);
return { content: [{ type: "text", text: result.summary }] };
}
}, { signal: controller.signal });下單工具即使存在，也只返回「需要使用者確認」，不能自行扣款。每次呼叫記錄工具版本、參數驗證結果和頁面狀態；評估集涵蓋錯誤商品、過量數量、過期價格、拒絕確認和 WebMCP 不可用。這樣 WebMCP 是可撤銷的漸進增強，業務授權和使用者意圖仍由現有鏈路決定。
常見錯誤
- 把 WebMCP 早期試用功能描述成穩定的後端 API。
- 暴露一個能直接付款、刪除帳戶或修改任意地址的萬能工具。
- 只在瀏覽器端驗證 schema，伺服器端不再檢查登入、庫存、價格和冪等性。
- 讓跨來源 iframe 預設共享工具，或把完整使用者資料作為工具結果返回。
- 沒有正常 UI、能力偵測、撤銷註冊和代理評估集。
高品質回答應同時涵蓋工具契約、伺服器授權、來源隔離、使用者確認、降級和量化評估。只說「給按鈕加描述」無法證明互動安全。
追問及應對
為什麼不把下單也註冊成 WebMCP 工具？
可以註冊一個只負責準備訂單摘要的工具，但最終提交應由頁面確認和伺服器授權完成。工具呼叫本身不能證明使用者同意付款，也不能繞過價格、庫存和風控驗證。
如何限制跨來源 iframe 的工具暴露？
預設不暴露給跨來源上下文；確有需要時同時使用明確的 Permissions-Policy 和 iframe allow，並在工具層限制可讀寫的資料範圍。來源、頁面生命週期和撤銷路徑都應寫入日誌。
代理傳入 schema 合法但業務無效的參數怎麼辦？
前端先拒絕不可見商品、過期狀態和超出目前使用者範圍的輸入，伺服器再次執行業務驗證，返回結構化拒絕原因；不要把字串拼接成任意動作，也不要靜默修改參數。
如何證明代理真的理解工具？
用固定任務集和真實頁面評估工具選擇、參數合法率、完成率、誤呼叫率和拒絕正確率。對付款、刪除等高風險動作設定零誤呼叫門檻，並在 API 變更後重新評估。