題幹與適用場景
儀表板來自公開 HTTPS 來源，有時要存取私有位址的印表機和使用者裝置上的 localhost 助手，同時嵌入一個不應存取區域網路的供應商 iframe。請說明瀏覽器如何區分公開、區域和回環位址空間、何時需要使用者授權，以及拒絕後如何恢復。
應用授權、CORS 和裝置驗證仍需分開處理。瀏覽器權限是使用者同意邊界，不代表印表機屬於目前帳號。假設瀏覽器不支援 Local Network Access 時，產品可以提供手動設定路徑。
面試官考察點
核心訊號是能否把公開頁面存取私有端點視為安全邊界。強回答會指出路由器和印表機可能遭受 CSRF 類攻擊，並用安全內容、位址空間、權限狀態和 iframe allowlist 限制流程。
面試官還會追問你是否混淆 local-network 與 loopback-network，或把 CORS 預檢成功誤認為已取得存取權。好的回答會把策略、權限、混合內容、CORS 和裝置驗證拆成獨立閘門。
回答前需要釐清的問題
- 目標是否預先固定，還是允許使用者輸入任意 IP？任意掃描需要不同的產品邊界，不能藏在普通「連線」按鈕後。
- 助手只在
localhost，還是也可能位於私有子網路？這決定使用回環還是區域網路權限。 - 供應商 iframe 或巢狀 frame 是否可能發起請求？若可能，每個 frame 邊界都要明確委派能力和可能的導覽來源。
- 支援哪些瀏覽器和企業策略？不同瀏覽器的發布時間不同，相容路徑應可觀察，不能悄悄降低安全性。
30 秒回答框架
「我會讓儀表板保持 HTTPS，先把目標分類為公開、區域或回環，再在需要時請求對應瀏覽器權限。回應策略拒絕供應商 iframe 的區域存取；若可信任 iframe 必須連線，就只給確切來源和全部導覽來源設定 allow。動作前檢查權限狀態，說明用途，分別處理混合內容和 CORS，給不支援的瀏覽器提供手動設定。測試要證明任意主機和生產廣告 frame 永遠不能觸發區域請求。」
分步驟深入解答
第一步：定義信任邊界和位址空間
公開網站不能靜默向使用者路由器、印表機或開發服務傳送改變狀態的請求。至少區分三類目標：公開位址可從網際網路存取；區域位址只在使用者網路內可達；回環位址只指向同一裝置。localhost 不等同於所有私有子網路。
請求清單還應包括 fetch、子資源、WebSocket、WebTransport、WebRTC、Service Worker 請求和 frame 導覽。某個函式庫開啟 socket 時，即使業務程式沒有直接呼叫 fetch，也可能越過同一邊界。
第二步：要求安全內容和明確權限
頁面使用 HTTPS。在支援的瀏覽器中，裝置動作前查詢相關權限：
const localState = await navigator.permissions.query({ name: "local-network" });
const loopbackState = await navigator.permissions.query({ name: "loopback-network" });把 granted、prompt 和 denied 當成產品狀態。彈窗前說明用途；拒絕後展示修復連結或手動設定，不要迴圈重試。HTTP 頁面應視為不支援，即使某個目標碰巧能回應。
第三步：限制嵌入文件
頂層回應只能委派必要能力和來源。供應商 frame 不取得區域能力：
Permissions-Policy: local-network=(self "https://dashboard.example"), loopback-network=(self "https://dashboard.example")可信任設定 frame 若必須連線，應收窄委派：
<iframe src="https://setup.example" allow="local-network https://setup.example; loopback-network https://setup.example"></iframe>回應策略和 iframe 策略取交集，frame 不能擴大父層拒絕。如果 frame 會導覽到也要存取區域的其他來源，就明確列出該來源，否則導覽後拒絕。巢狀 frame 的每層邊界都要有策略。
第四步：分開權限、混合內容和 CORS
權限不會讓所有不安全請求都合法。有些瀏覽器在使用者同意後允許特定區域 HTTP 端點，其他混合內容檢查仍可能生效。只有在瀏覽器和端點契約支援時，才使用請求的目標位址空間資訊；不能把它當成公開目標的繞過開關。
CORS 決定目標是否允許目前來源讀取回應，並不授權公開頁面存取印表機，也不能取代裝置驗證。改變狀態的命令應使用裝置專屬挑戰或配對碼，並保證命令具冪等性。
第五步：設計降級和遙測
不支援的瀏覽器應提供手動 IP、原生助手或引導式配對。記錄目標類別、權限狀態、策略結果、瀏覽器能力、CORS 結果和裝置驗證結果，不記錄憑證或區域回應原文。若發布後出現新的目標類別請求區域存取，或廣告 frame 嘗試存取，應觸發告警。
第六步：測試負向矩陣
測試 localhost、私有 IP、解析為公開位址的公開主機名、解析為區域位址的公開主機名、HTTP 頁面、缺少權限、拒絕權限、缺少 iframe 委派、巢狀 frame、導覽到未列出的來源、CORS 拒絕、裝置驗證失敗，以及 DNS 解析期間位址類別變化。確認只有使用者明確動作能觸發彈窗，背景重試不會掃描位址段。
高品質示範回答
「我會把公開到區域的請求當成必須申請並收窄的能力。儀表板保持 HTTPS，分別判斷印表機和助手的目標類別，查詢 local-network 或 loopback-network 狀態，並在一次受限請求前解釋彈窗。回應策略拒絕供應商 iframe；可信任設定 iframe 只委派設定來源和它可能導覽到的來源。
我會把瀏覽器權限、混合內容、CORS 和裝置驗證分成不同閘門。瀏覽器拒絕或不支援時走手動配對，不反覆請求。測試覆蓋區域、回環、公開、DNS 重新分類、巢狀 frame、缺少委派、權限拒絕、CORS 和裝置驗證失敗。廣告或任意主機能觸發請求或彈窗時立即停止發布。」
常見錯誤
- 把所有私有 IP 當作回環 → 回環與區域網路權限語意不同 → 先判斷目標位址類別。
- 拒絕後持續重試 → 會造成騷擾和掃描行為 → 只解釋一次並提供修復路徑。
- 認為 CORS 就能信任印表機 → CORS 控制回應共享，不證明裝置身分 → 配對裝置並驗證命令。
- 給供應商 frame
local-network *→ 重新導向和巢狀文件會擴大信任集合 → 列確切來源或拒絕委派。 - 只用 localhost 測試 → 可能沒有覆蓋公開到區域邊界 → 從公開 HTTPS 測試來源存取各類位址。
追問及應對
追問一：開發環境的 localhost 正常，生產為什麼失敗？
開發環境可能來自回環來源，或瀏覽器尚未啟用新限制。生產是公開來源存取回環或區域空間，會同時遇到安全內容、權限、策略、混合內容和 CORS 閘門。應從公開 HTTPS 測試來源重現。
追問二：iframe 會自動繼承頂層權限嗎？
只能在策略和委派規則允許時繼承。跨來源 frame 需要明確能力授權，巢狀 frame 還需要逐層委派。使用者決定綁定嵌入內容，但不能繞過缺少 allow 或未列出的導覽來源。
追問三：agent.example 的 DNS 從公開位址變為私有位址怎麼辦？
重新判斷解析位址並要求相應權限和安全內容路徑，不能永久快取公開分類。記錄分類變化；若目標不在核准集合中，預設失敗。
追問四：為什麼有權限彈窗仍不足以執行印表機命令？
彈窗只表示使用者允許該站點進行網路存取，不會驗證裝置或授權操作。應配對裝置，把命令綁定帳號和 nonce，並讓重試具冪等性。