題干與適用場景
你負責一個儀表板，嵌入 meet.example 會議、video.example 播放器和多個廣告 frame。會議需要 microphone 與 camera，播放器需要 fullscreen，廣告不需要這些能力。頁面使用 HTTPS；來源已知；策略允許時瀏覽器仍應向使用者請求媒體授權。
題目範圍是瀏覽器策略組合與故障診斷。CSP、身分驗證和伺服器授權仍是獨立控制。假設儀表板伺服器設定回應標頭，且每個跨來源 frame 都明確設定 allow。
面試官考察點
面試官會看你能否拆開三個閘門：回應策略、frame 委派、使用者執行時授權。只有回應標頭列出來源並不會自動給跨來源 frame 權限；allow 也不能擴大被回應標頭拒絕的能力。
強回答從敏感能力的 () 預設拒絕開始，寫出精確來源、處理導覽與巢狀 frame，並說明 API 不可用時的介面行為。弱回答會直接寫 *、等待權限彈窗，再把「安全」當成結論。
回答前需要釐清的問題
- 會議 frame 可能導覽到哪些確切來源？導覽到新來源後，原有能力可能需要重新委派，否則應被拒絕。
- 會議 frame 是否還會巢狀其他 frame？如果會，要定義委派能否繼續，並逐層驗證實際來源。
- 支援哪些瀏覽器和嵌入式 WebView？語法正確不代表所有執行環境的失敗表現相同。
- 相機和麥克風是否必要？若可選，策略拒絕或使用者拒絕時可以提供文字通話路徑。
30 秒回答框架
「我會把相機和麥克風預設設為 ()，只在回應策略中授予會議來源；全螢幕只授予影片來源。每個跨來源 iframe 再透過 allow 寫出所需能力，因為回應標頭和 frame 策略缺一不可。frame 分開辨識策略拒絕與使用者拒絕，展示降級路徑，不把權限彈窗當成授權依據。上線前測試同來源、跨來源、導覽、巢狀 frame、缺少回應標頭和瀏覽器降級。」
分步驟深入解答
第一步：建立預設拒絕清單
列出頁面使用的每項策略控制能力及其所屬來源，不要從「會議」這個產品名稱推斷權限。相機、麥克風是兩項獨立能力；全螢幕是另一項；廣告屬於明確的零權限類別。
可以使用明確的回應標頭：
Permissions-Policy: camera=(self "https://meet.example"), microphone=(self "https://meet.example"), fullscreen=(self "https://video.example")精確來源清單可以阻止無關 frame 取得授權。如果儀表板自身也不應存取某能力，就移除 self，只授予必要的 frame 來源，同時確認父策略仍允許委派。
第二步：在每個 iframe 邊界委派
會議 frame 只得到兩項能力，影片 frame 只得到全螢幕：
<iframe src="https://meet.example/room" allow="camera; microphone"></iframe>
<iframe src="https://video.example/player" allow="fullscreen"></iframe>
<iframe src="https://ad.example/slot" allow=""></iframe>跨來源 frame 即使回應標頭列出了來源，省略 allow 仍會被攔截。反過來，給廣告加 allow="camera" 也不能覆蓋 camera=() 或回應標頭中沒有列出的來源。
第三步：分開處理策略與使用者同意
Permissions-Policy 決定文件能否使用能力；Permissions API 與媒體彈窗代表使用者授權。策略阻斷可能發生在彈窗出現之前。frame 應把「策略拒絕」「使用者拒絕」「不支援」和「裝置佔用」分開記錄並給出恢復動作。
客戶端檢查不是安全邊界。嵌入頁控制委派，應用仍需在伺服器端驗證通話並檢查房間成員資格。
第四步：明確處理導覽與巢狀 frame
如果會議 frame 能導覽到支援來源，只有在該來源可信且確實需要相同能力時，才把目的來源加入 allow 策略。初始 src 來源和之後的導覽來源不是同一個授權物件。巢狀 frame 要逐層檢查有效策略，歸屬不明時預設拒絕。
第五步：用可觀察測試上線
在平台允許的情況下先以診斷或小流量路由觀察，再比較策略違規、彈窗結果、通話完成率和降級使用率。測試同來源 frame、已允許跨來源 frame、未列出的跨來源 frame、缺少 allow、變化的子網域和 frame 導覽。應斷言廣告永遠不會觸發彈窗，會議被拒絕時會顯示文字聊天。
高品質示範回答
「我會從威脅模型寫策略。相機和麥克風先設為空權限，只在回應標頭列出 meet.example；全螢幕只列出 video.example。兩個跨來源 frame 帶匹配的 allow，廣告 frame 不帶能力。瀏覽器仍負責使用者同意，所以會議程式要區分策略攔截和使用者拒絕，並提供文字降級。這個標頭不負責房間授權，伺服器仍要檢查身分和成員關係。
上線前我會覆蓋矩陣：允許與未列出的來源、同站但跨來源的子網域、省略 allow、frame 導覽、巢狀 frame、不支援瀏覽器和缺失回應標頭。遙測只記錄能力、frame 來源、策略結果、使用者結果和降級，不記錄媒體內容。廣告出現意外彈窗，或導覽到不可信來源後仍能使用能力，就暫停發布。」
常見錯誤
- 相機和麥克風使用
*→ 任意合資格 frame 都可能請求敏感能力 → 從()開始，只添加確切來源。 - 只設定 HTTP 標頭 → 跨來源 iframe 還需要容器委派 → 設定匹配的
allow。 - 只設定
allow→ frame 不能擴大父策略 → 同時檢查回應標頭和每個 frame 邊界。 - 把沒有彈窗當成瀏覽器故障 → 策略拒絕可能早於使用者同意 → 分開記錄策略、使用者、支援性和裝置狀態。
- 認為子網域就是同源 → 同站不等於同源 → 逐個列出來源並測試導覽。
追問及應對
追問一：回應標頭列出了會議來源，為什麼功能仍被攔截？
檢查 iframe 的 allow、協定與埠是否完全匹配，以及 frame 是否已導覽。跨來源 frame 的回應策略與容器策略取交集，任一授權缺失都會阻斷能力。
追問二：能否省略回應標頭，只依賴 allow？
不能。明確的回應策略給頁面所有者提供頂層邊界，避免新增第三方 frame 時意外放權。省略策略可能讓某些能力採用寬鬆預設值，第三方嵌入就可能形成回歸。
追問三：會議 frame 導覽到支援網域時怎麼辦？
把目的來源當成新的授權物件重新評估。只有完成信任、驗證和資料處理審查後才授予相機或麥克風，否則導覽後應失去能力並展示降級說明。
追問四：Permissions Policy 能取代伺服器端授權嗎？
不能。它控制文件中瀏覽器能力的可用性，不能證明使用者身分、房間成員關係或加入通話的業務權限。這些檢查仍由伺服器完成，策略只提供最小權限的瀏覽器邊界。