Azure國際企業帳號 微軟雲對象存儲跨域資源共享設定

第一章：為什麼跨域會卡住你

你在前端寫好功能後，常見情境是：頁面能正常跑，但一呼叫物件存儲的圖片、影片或資料，就立刻出現瀏覽器錯誤。表面上看是「請求失敗」，實際上更精準的原因通常是：瀏覽器用同源策略（Same-Origin Policy）保護了你的網站，只有在服務端允許的條件下，跨網域/跨協定的資源才會被回應並交給你的前端程式使用。

跨域資源共享（CORS, Cross-Origin Resource Sharing）就是服務端用來「明確授權」的機制。它不只是你在後端打開了某個開關，而是一套由瀏覽器發起、由服務端回傳特定響應頭的流程。尤其是當你要存取微軟雲的對象存儲時，很多人把它當成「能不能打開即可」，但實務上你必須理解方法（GET、PUT、POST等）、允許的來源（Origin）、以及是否需要支援預檢（OPTIONS）請求。

在微軟雲常見的物件存儲場景裡，你可能使用的是 Blob Storage 或其等價功能。無論你的應用是部署在不同域名、不同協定（https://與http://）、或不同子域之間，CORS 都會成為你面對的第一道門檻。問題的關鍵是：正確的 CORS 設定能讓瀏覽器信任伺服器的回應；反之，即使服務端真的返回了資料，前端也可能因為缺少必要的回應頭而拒絕使用。

第二章：CORS不是單一設定，而是一個決策鏈

要把跨域問題一次搞懂，你需要先理解 CORS 的核心元素。

1. Origin：你到底允許誰

瀏覽器會在請求中帶上 Origin 頭，格式通常是「協定 + 網域 + 端口」。例如：
https://app.example.com。服務端在回應中會用 Access-Control-Allow-Origin 告訴瀏覽器「允許哪個來源」。

很多人直接用通配符 *。對於只讀且不涉及憑證的情況，這確實能快速解決。但若你的請求會帶上憑證（例如 cookie、或前端設定了 credentials），通配符與憑證往往不能共用。你必須改成具體來源清單。

2. Methods：你要允許哪些動作

CORS 是針對「方法」的允許。你可能只需要 GET（讀取檔案），也可能要上傳 PUT，或用 POST 走流程。服務端需要在回應中說清楚允許的動作集合。

若你的前端呼叫的是 PUT，但 CORS 只允許 GET，你會看到瀏覽器拒絕讀取回應。這不是資料錯誤，是權限宣告錯誤。

3. Headers：自訂請求頭是否被允許

常見的錯誤是你以為只要允許方法就行了。實務上，當你使用自訂 header（例如 Authorization、x-ms-version、x-custom-id 等），瀏覽器可能需要在預檢階段（OPTIONS）先確認服務端願意接收這些 header。

若你看到錯誤訊息提到「被 blocked by CORS policy: No 'Access-Control-Allow-Headers'」之類的字眼，那通常就是 headers 集合沒對上。

4. Preflight（OPTIONS）：不是每次都會發，但一旦發就是關鍵

瀏覽器會對某些「非簡單請求」自動發送 OPTIONS 預檢。典型觸發條件包含：方法不是 GET/HEAD/POST，或含有非簡單 header，或 Content-Type 不是瀏覽器允許的簡單值。
預檢請求的意義是：先問服務端「你允不允許我這樣呼叫」，若服務端回覆的 CORS 標頭符合，瀏覽器才會發真正的請求。

因此，CORS 設定不只要覆蓋真正的 GET/PUT，也要確保 OPTIONS 能正確回應你需要的允許資訊。

第三章：在微軟雲對象存儲裡配置CORS的思路

不同微軟雲控制台或命令介面在表述上可能略有差異，但核心概念一致：你要為儲存服務（或容器/桶級別）定義 CORS 規則。這些規則通常會包含 AllowedOrigins、AllowedMethods、AllowedHeaders、ExposedHeaders、MaxAge 等欄位。

你可以把它想像成一組「配方」。每次瀏覽器請求物件存儲時，服務端會檢查 Origin 與請求方法/標頭，找出匹配的規則，然後在回應中加上對應的 Access-Control-Allow-* 標頭。

1. AllowedOrigins：建議用精準清單

如果你是內部系統或單一前端網域，請優先使用具體的 Origin 清單，而不是 *。例如：

允許：
https://app.example.com
https://admin.example.com

Azure國際企業帳號 原因很簡單：一旦你之後引入 credentials（例如你需要透過 cookie 進行存取），你就很難再使用通配符。更重要的是，精準清單讓你能在審計與風險控管時更清楚地說明授權範圍。

2. AllowedMethods：只開你真的需要的

常見的最小集合是 GET、OPTIONS（後者通常是隱含需求）。若你只讀取資源，就不要打開 PUT 或 POST。若你要上傳，才加上 PUT/POST，但仍應該以容器能力與安全需求為準。

3. AllowedHeaders：以實際請求為準

你要做的不是猜測，而是從瀏覽器或網路日誌中看清楚請求頭有哪些。例如「預檢請求」會明確列出 Access-Control-Request-Headers。你只要讓 AllowedHeaders 至少覆蓋你實際使用的那些，就能避免常見封鎖。

很多團隊在前期追錯時浪費時間，是因為他們看到錯誤只說「CORS blocked」，卻沒有把 OPTIONS 請求的回應與請求內容對起來。

4. ExposedHeaders：你想讓前端讀到哪些回應欄位

預設情況下，瀏覽器只允許前端讀取部分安全欄位。若你需要前端讀取某些自訂回應頭（例如檔案版本號、ETag、或某個業務狀態欄位），就需要在 ExposedHeaders 指定。

這個選項常被忽略，導致前端「看得到」資料但讀不到特定 header。你以為 CORS 只影響能否拿到資料，其實它也影響「你能否讀到」某些回應資訊。

第四章：常見錯誤拆解與修正策略

下面幾個錯誤幾乎是跨域問題的經典題。你只要對照自己的情況，通常能快速定位是哪一段環節出了問題。

錯誤一：你已經看到狀態碼200，但前端仍報CORS

這是最讓人困惑的狀況：服務端確實回了 200，但瀏覽器仍拒絕。原因通常是回應中缺少 Access-Control-Allow-Origin，或是 AllowedMethods/AllowedHeaders 不符合預檢結果。

修正策略：

• 打開瀏覽器開發者工具的 Network，找出真正被拒絕的請求。
• 查看該回應是否有 Access-Control-Allow-Origin / Access-Control-Allow-Methods / Access-Control-Allow-Headers。
• 若有預檢，先看 OPTIONS 的回應是否符合。

錯誤二：明明是GET，仍觸發預檢OPTIONS

理論上 GET 為簡單請求的機率較高，但若你在請求中加了某些 header，或 Content-Type 設定不在簡單集合內，就可能觸發預檢。

修正策略：

• 檢查請求頭是否包含 Authorization、或其他自訂欄位。
• 確認 Content-Type 是否是瀏覽器允許的簡單值（例如 text/plain、application/x-www-form-urlencoded、multipart/form-data 的某些條件）。
• 預檢發生時，你必須保證 OPTIONS 的 CORS 規則也能匹配。

錯誤三：AllowedOrigins用*但又開了credentials

當前端使用 fetch 或 XMLHttpRequest 並設置了 credentials（例如 fetch(url, {credentials:'include'})），瀏覽器會要求回應的 Access-Control-Allow-Origin 不能是 *。它必須是具體 origin，且還可能需要 Access-Control-Allow-Credentials:true。

修正策略：

• 把 AllowedOrigins 從 * 改為明確的來源清單。
• Azure國際企業帳號 確保前端 credentials 設置與後端回應一致。
• 不要只看是否能取得檔案內容，要看瀏覽器是否允許讀取回應。

錯誤四：檔案讀得出來，但前端讀不到ETag或自訂header

這通常不是「CORS不允許」，而是 ExposedHeaders 沒加。瀏覽器可能把回應頭遮住了，讓你無法用 JS 讀取。

修正策略：

• 確認你需要讀的回應頭是哪些欄位。
• 在 ExposedHeaders 中加入相應名稱。
• 重新測試，觀察 response headers 是否能在 JS 端取到。

第五章：一套可落地的驗證流程（從本地到上線）

很多團隊不是不知道 CORS 怎麼設定，而是缺少一套能快速驗證與回歸的流程。你可以用下面的方法把不確定因素降到最低。

步驟1：先確認請求行為與來源

先記下前端頁面的來源（Origin），以及請求方法、路徑、是否包含憑證。很多問題其實是「你以為跨域的是A到B，結果實際Origin是C」。尤其當你用反向代理、CDN 或不同環境（staging/production）時，Origin 會變。

同時確認你是否使用了 fetch/xhr 的 credentials、或是把 token 放在 Authorization header。這會影響是否觸發預檢，以及需要允許哪些 header。

步驟2：看預檢（OPTIONS）與真實請求兩份資料

打開瀏覽器 Network，篩選出 OPTIONS 和真正的 GET/PUT。對照兩份請求/回應中的 CORS 相關欄位：

• OPTIONS 回應是否包含 Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Allow-Origin。
• 真實請求回應是否包含 Access-Control-Allow-Origin，且必要時也包含 Access-Control-Allow-Credentials。

如果 OPTIONS 已經被擋下，那你往往根本不會看到真實請求成功。若 OPTIONS 允許但真實請求仍被擋，那多半是回應頭缺漏或 Origin 不匹配。

步驟3：逐步縮小授權範圍

調試階段常有人先用最寬鬆設定（例如 AllowedOrigins=*、AllowedMethods=*）換取快速驗證，但上線前一定要收斂。原因不只是安全，還因為你要避免未來環境變動導致隱性問題。

收斂方式建議是：

• 先鎖定 Origin：用明確網域替代 *。
• 再鎖定 Methods：只保留你用得到的方法。
• Azure國際企業帳號 最後鎖定 Headers：允許清單以實際請求為主。

步驟4：加入可觀測性，避免「看不見的失敗」

跨域問題往往在瀏覽器端表現，後端卻可能仍有正確回應。建議你把以下資訊在日誌或追蹤中保留下來：

• Azure國際企業帳號 請求來源 Origin（或至少記錄其域名部分）。
• 請求方法與路徑。
• 若可能，記錄是否命中某個 CORS 規則。

在微軟雲的環境裡，你通常可以配合監控與診斷設定觀察儲存服務事件。這能讓你不必完全靠前端錯誤訊息猜測。

Azure國際企業帳號 第六章：上傳與下載的差異：CORS不是只看讀取

很多文章只講 GET。實務上，前端常常要上傳檔案或直接對物件存儲進行寫入操作。這時 CORS 會變得更敏感。

上傳場景：PUT/POST通常更容易踩雷

上傳通常涉及非簡單請求或自訂 header。即使你允許了 GET，PUT 沒有在 AllowedMethods 中，就會直接失敗。除此之外，如果上傳要帶上授權資訊（例如簽章、token、或其他 header），還要確保 AllowedHeaders 覆蓋這些值。

你也要注意：部分架構會先用服務端產生簽名 URL（例如短期授權的方式），前端只做直接上傳。這時 Origin 必須被允許，而授權 header 的方式可能和讀取不同。你要用同一套思路逐一比對。

下載場景：重點在來源、回應頭與快取

下載 GET 通常相對單純，但你仍可能遇到兩類問題：第一是 CORS header 沒返回；第二是你想從回應讀取某些資訊（例如 ETag、或自訂 metadata），而沒把 ExposedHeaders 設好。

此外，快取也會干擾你排查：你改了 CORS 規則，但瀏覽器仍用舊緩存。建議測試時在開發模式清除快取或用無痕視窗，確保你看到的是新設定效果。

第七章：把設定寫成可維護的規則

很多 CORS 事故是「臨時修好，卻不整理」。過了一段時間，團隊只記得某個寬鬆設定能用，卻不知道為什麼能用、在哪裡改過、哪些來源被授權。這會讓下一次部署或換網域時反覆踩同一個坑。

建議你把 CORS 規則當成配置文件管理：

• 為每個環境（dev/staging/prod）明確列出 AllowedOrigins。
• 在規則旁記錄應用用途：例如「讀取靜態資源」「前端直傳上傳」「管理端下載」。
• 保持規則數量可控，避免一口氣加十幾條讓排查失去邏輯。

當規則清晰，你會發現排錯也變得像找 bug：知道是哪一條規則、哪個 header、哪個方法在起作用，而不是靠直覺猜。

第八章：實戰建議：從一個小例子開始

假設你有一個前端網域：https://app.example.com，需要直接讀取容器中的圖片。前端用 fetch 或直接讓瀏覽器載入圖片，但你仍要讓 JavaScript 端能獲得資料或讀取部分 header。

你可以用以下思路規劃：

• AllowedOrigins：只放 https://app.example.com。
• AllowedMethods：至少包含 GET。若你發現有 OPTIONS 被用到，就確保規則覆蓋它（通常服務端會自動處理，但你仍要確保回應包含符合條件的 Allow 欄位）。
• Azure國際企業帳號 AllowedHeaders：若你只做簡單 GET，通常不需要放很多；但如果你帶了 Authorization 或自訂 header，就必須列上。
• ExposedHeaders：如果你要讀取 ETag 或自訂 metadata，就加入相應欄位。

做完後，你用開發者工具核對兩點：真實 GET 回應中是否有 Access-Control-Allow-Origin；以及你需要讀的 header 是否能被前端 JS 取得。

第九章：常見誤區與你該避免的做法

誤區一：只改前端，不改服務端

瀏覽器要求的是服務端回應特定 CORS header。前端再怎麼調整，除非你改成同源（例如用代理把請求變成同一網域），否則 CORS 仍會擋住。

誤區二：把所有方法都打開為了省事

寬鬆設定雖然容易通過測試，但會增加風險。尤其當你允許寫入方法時，就等於給了任何符合 Origin 條件的站點潛在操作能力。上線後你要對安全更有把握。

誤區三：忽略預檢回應

很多人直接看 GET 失敗，卻沒去看 OPTIONS。結果你以為你已經允許 GET，但其實預檢沒有返回正確 header，導致瀏覽器根本不發送或不使用真正回應。

誤區四：只用一次測試就確定完成

環境差異很常見：例如 staging 的網域不同、或某段程式在不同頁面會帶不同 header。你至少要測試兩種常見路徑：一是你預期最常用的功能；二是帶上你認為不常用但其實真會觸發預檢的條件（例如帶 token 或自訂 header 的版本）。

第十章：結語——讓跨域不再靠運氣

微軟雲對象存儲的跨域資源共享設定，表面上是幾個欄位的配置，實際上是瀏覽器安全機制與服務端回應宣告之間的契約。你要做的不是盲目加大權限，而是理解 Origin、Methods、Headers 與預檢流程，然後用可觀測的方式驗證每一步。

Azure國際企業帳號 當你建立了驗證流程（看 OPTIONS、對照回應 header、再逐步收斂授權範圍），跨域問題就會從「玄學」變成「工程」。你修一次，就更懂一次；下一次換域名或改上傳流程時，你不必再從零猜。CORS 正確設好了，前端才真的能把功能做到位。