CORS到底在保護誰？掘金長文主張「保護對象是瀏覽器裡的用戶，不是服務端」

掘金作者ErpanOmer於2026年11月4日刊出一篇關於跨域資源共享（CORS）的技術長文，主張多數前端工程師對CORS的理解存在根本偏差：CORS並非服務端的防護機制，而是瀏覽器保護用戶身份的安全設計。文章以銀行轉帳攻擊場景與後端常見的危險配置為例，說明「後端加個CORS頭就通了」背後被忽略的風險。

文章的核心主張

作者開篇以常見的開發場景切入：新人聯調接口時，瀏覽器控制臺彈出跨域報錯，向後端求助，後端加上Access-Control-Allow-Origin標頭後接口即通。作者認為，這種「配完就不用管」的處理方式，反映出一個普遍且危險的誤解。

文中指出，服務端不需要CORS保護自己。任何人都可以用curl、Postman或後端程式碼直接呼叫接口，CORS對此毫無攔截能力。CORS真正防止的情境是：用戶打開一個惡意網頁後，該網頁內的JavaScript以用戶的身份（Cookie）偷偷呼叫其他網站的接口。

文章給出一個假想的攻擊例子。若瀏覽器沒有同源策略與CORS，一個惡意頁面可以在用戶不知情下，以credentials: ‘include’向銀行轉帳接口發送POST請求。由於請求帶有合法的登入Cookie，銀行服務端會認定是本人操作。作者強調，用戶「什麼都沒做，只是打開了一個網頁」。

星號配置與Origin反射寫法的風險

針對Access-Control-Allow-Origin: *的用法，文中做了區分。對天氣API、匯率查詢、公開CDN資源等不需用戶身份的公開接口，使用星號沒有問題。但對登入、支付、個人資訊、後臺管理等涉及用戶身份的接口，星號配置會形成安全缺口。

作者說明，瀏覽器有一條硬規則：Access-Control-Allow-Origin: *與credentials: include不能同時使用。若接口返回星號，瀏覽器會拒絕在請求中攜帶Cookie，這是瀏覽器代為設下的底線。

文章進一步指出一種比星號更危險的後端寫法：把請求標頭中的Origin值原樣反射回Access-Control-Allow-Origin，並同時設置Access-Control-Allow-Credentials: true。作者展示了一段Python Flask風格的after_request程式碼範例，說明這種配置讓任何網站的請求都能帶著用戶Cookie訪問接口，既繞過了瀏覽器對星號的限制，又打開了允許攜帶憚據的安全漏洞。前述銀行轉帳的攻擊場景，在這種配置下即為可行。

脈絡與可核實邊界

CORS由全球資訊網協會（W3C）規範定義，現由WHATWG維護Fetch標準的一部分，其與同源策略構成瀏覽器的安全模型基礎。文中關於星號與憑證不可併用的說法，與Fetch標準的規範內容相符；Origin反射寫法的安全風險，過去亦曾在多篇資安討論中被提及。

需說明的是，本文的攻擊場景與「90%的前端理解錯了」的比例均屬作者的修辭說法，並非可核實的統計數據。文章截至可查閱的版本顯示閱讀量極低，屬新刊出狀態。

同類瀏覽器安全與前端機制議題，可對照本臺先前整理的前端選圖與DPR的技術脈絡一文；而前端職缺對基礎能力的重視趨勢，亦可參考647條大廠前端職缺的統計整理。