同源策略
同源策略（Same-Origin Policy, SOP） 是一種Web瀏覽器的安全機制，旨在防止不同來源的惡意網頁相互訪問用戶的敏感數據，以保護用戶的隱私和安全。同源的概念基于以下三個要素：
- ?協議?（如
http和https） - ?域名?（如
example.com） - ?端口?（如
80和443）
同源策略規定，只有當兩個URL的協議、域名、以及端口號完全相同時，它們才被視為相同源（Same-Origin），并可以互相訪問資源。這一機制主要限制了JavaScript代碼和文檔對象模型（DOM）的跨源交互。
XHR的同源策略
XMLHttpRequest（XHR） 是一種用于在客戶端與服務器之間進行數據通信的API。XHR同源策略規定，頁面只能向與其相同源的服務器發送請求并接收響應。假如一個網頁在 example.com 上運行，它只能通過XHR請求訪問該域的數據，而不能請求其他域名下的資源。
舉例來說：
- ?允許?：從
example.com/page發送請求到example.com/api - ?不允許?：從
example.com/page發送請求到another-domain.com/api
Cookie的同源策略
Cookie 也是同源策略的關鍵組成部分。當一個網頁在瀏覽器中設置了Cookie，這個Cookie只能被同源的頁面訪問。這意味著只有具有相同協議、域名和端口的頁面才能讀取或發送這些Cookie，防止跨站點的Cookie劫持或濫用。
XHR與Cookie的同源策略差異
對于子域名，同源策略在XHR和Cookie處理上有所不同：
- ?XHR限制嚴格?：子域名無法通過XHR訪問父域名的資源，反之亦然。
- ?Cookie共享?：Cookie默認可以在父域名和子域名之間共享。例如，
example.com的Cookie可以在sub.example.com中使用，前提是Cookie的Domain屬性已正確設置。
CORS（跨源資源共享）
跨源資源共享（Cross-Origin Resource Sharing, CORS） 是一種允許瀏覽器從不同源請求資源的機制。它通過服務器配置的HTTP頭部來明確聲明哪些域名能夠訪問其資源，從而打破了同源策略的限制。
CORS的關鍵頭部
CORS機制通過在請求和響應中添加特定的HTTP頭部來管理跨源請求。以下是一些重要的CORS相關頭部：
- ?Origin?：標識發起請求的來源（瀏覽器會自動添加）。
- ?Access-Control-Allow-Origin?：指定哪些源被允許訪問資源。例如，可以設為特定域名或者通配符
*，以允許所有域請求。 - ?Access-Control-Allow-Methods?：定義被允許的HTTP請求方法，如
GET、POST、DELETE等。 - ?Access-Control-Allow-Headers?：列出允許客戶端使用的自定義請求頭部。
- ?Access-Control-Expose-Headers?：指定哪些頭部可以在客戶端代碼中訪問到。
簡單請求（Simple Request）
CORS定義了一種特殊情況——?簡單請求?，瀏覽器可以不進行預檢而直接發送請求。滿足以下條件的請求通常被視為簡單請求：
- 使用的HTTP方法是
GET、POST或HEAD。 - 請求頭中只包括安全的頭部，如
Accept、Content-Type（其值限定為application/x-www-form-urlencoded、multipart/form-data或text/plain等）。
如果請求不滿足這些條件，瀏覽器將視其為?復雜請求?，并首先發送預檢請求。
CORS預檢請求（Preflight Request）
對于?復雜請求?，瀏覽器在發送實際請求之前，會通過 OPTIONS 方法向目標服務器發出一個預檢請求。該請求詢問服務器是否允許跨源請求以及允許的請求方法、頭部等。服務器收到預檢請求后會返回一個響應，明確指出哪些操作被允許，瀏覽器根據這些信息決定是否繼續發送實際請求。
CORS的安全性
盡管CORS提供了跨源請求的便利性，但如果不正確配置，可能會導致安全隱患。特別是，如果服務器隨意允許所有來源訪問，可能會使應用程序暴露在跨站點請求偽造（CSRF）或其他攻擊之下。因此，服務器在響應中應嚴格指定允許的源、方法和頭部，并小心處理允許跨源請求的資源類型，確保不引發敏感數據泄露問題。
總結
同源策略和CORS是Web安全的核心機制之一。通過同源策略，瀏覽器可以有效限制跨源請求和數據訪問，防止惡意網頁竊取敏感信息。而CORS提供了一種合法打破同源限制的方式，允許不同域之間安全、受控地共享資源。然而，CORS的使用需謹慎配置，以避免潛在的安全問題。
