今天我們就接著聊聊同源政策

什麼是同源政策 (Same-Origin Policy)？
同源政策是瀏覽器內建的一個核心安全機制。它的核心原則是：一個來源 (Origin) 的腳本 (Script) 只能存取來自相同來源的資源，而不能存取來自不同來源的資源。

這個政策的目的是為了保護使用者的資料與 session 的完整性。試想一個情境：
你在瀏覽器的一個分頁登入了你的網路銀行 (https://mybank.com)。
接著，你在另一個分頁打開了一個惡意網站 (https://iambadguy.com)。

如果沒有同源政策，iambadguy.com 頁面上的 JavaScript 腳本將可以直接向 mybank.com 發送請求，讀取你帳戶的餘額、交易紀錄，甚至模擬你的操作進行轉帳。因為瀏覽器在發送請求時會自動帶上 mybank.com 的 Cookie，這個請求將會是已認證的狀態。

同源政策的存在，就是為了防止這種跨來源的惡意存取行為。瀏覽器會自動攔截 iambadguy.com 的腳本，不允許它讀取來自 mybank.com 的回應內容，從而保護了你的資料安全。

再來我們來看看
「同源」的定義
要判斷兩個 URL 是否「同源」(Same-Origin)，必須同時滿足以下三個條件完全相同：

一、協定 (Protocol): 例如 http:// vs https://。
二、主機名稱 (Hostname / Domain): 例如 www.example.com vs api.example.com。
三、通訊埠 (Port): 例如 http://example.com:80 vs http://example.com:8080。

如果以上三者有任何一個不匹配，就會被視為「不同源」(Cross-Origin)。

所以同源政策限制了什麼？
SOP 主要限制的是腳本的讀取權限。具體來說，它主要影響以下幾個方面：

AJAX/Fetch API 請求: 這是最常見的限制場景。從 A.com 的 JavaScript 程式碼發出的 XMLHttpRequest 或 Fetch 請求到 B.com 的 API，請求本身可以被發送出去，但瀏覽器會阻止 A.com 的腳本讀取 B.com 回應 (response) 的內容。這就是所謂的跨域請求限制。

DOM的存取: 一個頁面無法透過腳本存取 iframe 中載入的不同源頁面的 DOM。例如，A.com 的頁面無法讀取或操作嵌入的 B.com iframe 裡面的內容。

Cookies, LocalStorage, IndexedDB: 腳本無法讀取或寫入不同源的儲存資料。A.com 的腳本無法存取 B.com 設下的 Cookie。

這大概就是同源政策的內容，有興趣的同學可以再去了解更深入的設定方式，明天的主題是關於網站伺服器的話題，然後接著是後端程式語言，再來我們就會開始進入滲透測試跟web security的議題嘍