如果未來 Frontend 和 AI Backend 的來源不同，Frontend 還能直接讀取 Backend 回傳的分析結果嗎？因此今天想了解 CORS，以及在將 AI 功能做成 Web 服務時，跨來源存取可能遇到的限制，方便之後在前後端分開部署或串接不同來源的 API 時，知道為什麼會遇到跨來源存取的問題，以及該注意哪些安全設定。

Origin 是什麼？

Origin 可以透過 Protocol、Host 和 Port 來判斷。它對應到目前的 Frontend 和 Backend，如果兩邊使用不同的 Port，即使都是 localhost，仍然屬於不同的 Origin。這時 Frontend 對 Backend 發送 Request，就會變成 Cross-Origin Request 。

為什麼 Browser 要限制不同 Origin？

這就要先說到 Browser 的 Same-Origin Policy (同源政策)，它主要是限制一個 Origin 的網頁任意讀取其他 Origin 的資料。有時候即使 Server 本身有在正常執行，Request 的網址也沒問題，但 JavaScript 可能因為 Browser 的安全限制而無法取得 Response。一開始會覺得這個限制很麻煩，但它其實就像一道安全界線。如果使用者同時登入某個網站，又不小心開啟惡意網站時，而沒有 Browser 限制不同來源之間的存取，惡意網頁就可能嘗試讀取其他網站回傳的資料。所以有了這個限制，就可以避免不同來源的網站可以任意讀取彼此的資料。

CORS 是什麼？

全名為 Cross-Origin Resource Sharing，是一種可以跨來源共享網站資料的機制，它會讓 Server 告訴 Browser，哪些 Origin 可以存取自己的資源。在實際開發時，Frontend 和 Backend 可能被放在不同的 Origin
因此不能因為怕被惡意網站讀取，就完全禁止跨來源存取。這時 Server 就可以透過 CORS 相關的 Response Header，告訴 Browser 哪些 Origin 被允許讀取自己的資源。

CORS 允許 Origin 的標準？

例如在 Network 中看到：Access-Control-Allow-Origin: *，其中 * 代表允許所有 Origin。而 Access-Control-Allow-Origin: [http://127.0.0.1:5500]，則代表只允許這個 Origin 的網頁跨來源讀取 Response。如果設定得太嚴格，可能會發生 Backend 正常回傳資料，Frontend 卻因為 Browser 的限制而讀不到 Response；但如果為了解決 CORS Error，而把允許範圍設的過於寬鬆，也可能讓原本沒有預計開放的網站取得跨來源讀取 API 回應的權限。因此在設定 CORS 時需要考慮允許哪些來源存取。如果沒有理解這些設定的用途，就可能在不知情的情況下放寬原本的安全限制，增加不必要的安全風險。