題幹與適用情境
Gateway API v1.5 將 HTTPRoute CORS 過濾器提升到 Standard channel。它允許在路由規則上宣告允許的來源、方法、請求標頭、暴露標頭與預檢快取時間。題目考察你能否把跨域策略放在合適的 Gateway 邊界，同時保留服務端鑑權與實作差異的驗證。
面試官考察點
面試官會看你是否區分瀏覽器 CORS 保護、Gateway 回應標頭和真正的身分授權。強回答會說明 preflight 的 OPTIONS 路徑、憑據與來源設定、通配符風險、不同路由的最小權限，以及 Gateway 實作是否支援此過濾器。只寫 allowOrigins: "*" 無法證明安全設計。
回答前需要釐清的問題
哪些來源與資源需要跨域
列出生產來源、預覽來源、管理後台與本地開發地址，按路由而不是整個網域空間授權。來源清單應可稽核、可過期，並避免把測試網域帶入生產。
是否攜帶憑據
確認請求是否帶 Cookie、HTTP 身分驗證或其他憑據。憑據請求需要更嚴格的來源和回應標頭策略，不能把任意來源與憑據組合成預設設定。
誰負責鑑權與策略發布
明確 Gateway、應用服務和身分服務的職責。CORS 只決定瀏覽器是否允許腳本讀取回應，不能取代 Token 驗證、租戶隔離或資源授權。
30 秒回答架構
「我先按 HTTPRoute 和業務資源劃分來源，不在全域 Gateway 上放寬權限。對每條路由設定明確的 origins、methods、headers、exposeHeaders 與 maxAge；有憑據時使用受控來源並驗證回應標頭。接著測試 OPTIONS 預檢、實際請求、錯誤回應與快取過期，確認 Gateway 實作支援此過濾器。最後把 CORS 作為瀏覽器存取控制，與服務端鑑權、稽核和回滾流程分開驗證。」
分步深入解答
第一步：按路由建立最小權限
為每個 HTTPRoute 記錄資源、來源、允許方法與標頭需求。公共唯讀資源與帶憑據的帳戶資源應使用不同規則，避免一條寬鬆策略覆蓋整個網域。
第二步：設定過濾器欄位
依需求設定 allowOrigins、allowMethods、allowHeaders、exposeHeaders 與 maxAge。來源模式要經過實作文件和安全評審，優先列出明確 origin，避免不必要的通配符。
第三步：正確處理預檢
瀏覽器會傳送帶有 Origin、Access-Control-Request-Method 與可能的 Access-Control-Request-Headers 的 OPTIONS。Gateway 必須回傳與策略一致的 CORS 回應標頭，不允許時要明確拒絕，而不是把預檢轉送給不理解 CORS 的後端。
第四步：分離憑據與鑑權
憑據策略應與 Cookie 屬性、CSRF 防護、Token 驗證和服務端授權一起設計。即使瀏覽器阻止腳本讀取回應，服務端也必須對請求本身執行身分與權限檢查。
第五步：驗證實作差異與發布回滾
確認使用的 Gateway controller 支援 v1.5 Standard CORS 過濾器及欄位語意。用真實瀏覽器和 curl 重現預檢、實際請求、失敗狀態、重新導向與快取行為，記錄策略變更、指標和回滾步驟。
高品質示範回答
我會先把來源按每個 HTTPRoute 劃分，公共搜尋介面和帶 Cookie 的帳戶介面不共用一條 CORS 策略。對每條規則明確允許的來源、方法、請求標頭、暴露標頭與預檢快取時間；如果需要憑據，我只允許經過審核的生產 origin。發布前用瀏覽器測試 OPTIONS 預檢和實際請求，確認錯誤回應、重新導向和快取過期都不會洩露過寬權限，再用 curl 和 Gateway controller 的狀態條件確認設定生效。CORS 只負責瀏覽器讀取邊界，服務端仍執行身分、租戶和資源授權；任何 controller 欄位語意不一致，都先在相容性矩陣中標記並保留應用層回退。
常見錯誤
- 錯誤表現： 全域允許任意來源。→ 失敗原因： 任何路由都可能被瀏覽器腳本讀取，稽核和撤銷困難。→ 修正方法： 按 HTTPRoute 建立最小來源集合。
- 錯誤表現： 只設定實際請求，不處理 OPTIONS。→ 失敗原因： 複雜方法或請求標頭會先被預檢阻擋。→ 修正方法： 對預檢和實際請求分別測試回應標頭與狀態碼。
- 錯誤表現： 把 CORS 當成鑑權。→ 失敗原因： 非瀏覽器客戶端仍可直接呼叫服務。→ 修正方法： 保留服務端身分、租戶和資源授權檢查。
- 錯誤表現： 未驗證 controller 就上線 v1.5 欄位。→ 失敗原因： 實作可能忽略、拒絕或解讀不同。→ 修正方法： 檢查支援矩陣、狀態條件與真實流量回放。
追問及應對
追問一：為什麼不直接在應用服務設定 CORS？
應用層仍可負責資源特有策略；Gateway 適合統一處理路由級預檢與跨服務邊界。兩層同時設定時要定義優先順序，避免重複或衝突回應標頭。
追問二：maxAge 設得越長越好嗎？
不是。更長的預檢快取可減少 OPTIONS 流量，但會延遲策略撤銷。應按變更頻率、風險與瀏覽器行為選擇，並在緊急撤銷時準備版本化來源或更短 TTL。
追問三：通配符來源何時可接受？
只有在資源確實公開、沒有憑據且風險評估允許時才考慮。帳戶、管理和租戶資料應使用明確來源，並驗證實作對通配符和憑據的處理。
追問四：如何發現某個來源被誤放行？
記錄 Origin、路由、預檢結果和策略版本，建立來源變更稽核；用自動化矩陣從允許、未允許和過期來源發起請求，發現回應標頭與預期不一致就阻斷發布。