概述
同源策略（SOP）是Web瀏覽器強制執行的一種安全策略，用於控制對網站和Web應用程序之間數據的訪問。 沒有SOP，任何網頁都將能夠訪問其他頁面的DOM。 這將使它可以從另一個網頁訪問潛在的敏感數據，以及在未經用戶同意的情況下在其他網頁上執行操作。
SOP不是Internet標準或固定規則，而是通用的瀏覽器安全策略。 不同的瀏覽器對它的解釋不同。 對於不同的技術（例如cookie），它的工作方式也有所不同。 但是，總體思路保持不變：幫助確保沒有未經授權的跨站點訪問。
源指的是什麼
用網絡術語來說，來源是網絡資源的一組共同特徵。 在大多數情況下，源是三個元素的組合：模式（協議），主機名（域/子域）和端口。 因此，由協議 域名 端口標識的所有資源都具有相同的來源。 但是，只要其中之一不相同，現代瀏覽器（例如Google Chrome或Mozilla Firefox）也會認爲這些資源具有不同的來源。 僅在使用Microsoft Internet Explorer的情況下，該端口才不視爲來源的一部分。
舉例說明
- http://www.example.com/page.html and http://www.example.com/subpage/page2.html HTML
三要素都一樣所以是同源的 - http://www.example.com/page.html and https://www.example.com/page.html
是不同的源，因爲協議不同。http 和 https - http://www.example.com/page.html and http://example.com/page.html
是不同的源因爲子域名不同
http://www.example.com/page.html and http://www.example.com/page.html:8080
是不同的源因爲端口不同
同源策略的應用場景
在不同來源的元素之間可能發生交互作用的所有情況下，瀏覽器都會應用原始檢查。 這包括但不限於：
- 例如，JavaScript代碼和文檔對象模型（DOM），頁面無法訪問其iframe的內容，除非它們具有相同的來源。
- Cookies，例如，您針對特定站點的會話Cookie不能發送到來源不同的頁面。 但是，對於cookie，不評估架構和端口，僅評估域/子域。
- AJAX調用（XmlHTTPRequest）。
同源策略不能完全解決不同源之間的相互作用 以下的一些情況也會有允許跨域的情況。
- 可以在不同的源之間提交表單。 例如，您可以創建跨域鏈接，也可以跨域提交表單。
- 通常可以在原點之間嵌入。 例如，可以在iframe中使用其他來源的內容（如果X-Frame-Options允許），或者在其他站點中嵌入img，css或腳本。
但是，原點之間的讀取通常被阻止。 這通常意味着您可以發送跨域請求，但無法讀取回復。
直接看如何解決
在nginx server塊添加配置
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT,OPTIONS, DELETE';
add_header 'Access-Control-Allow-Headers' 'Authorization,DNT,X-Token,token,TOKEN,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
#access_log logs/host.access.log main;
if ($request_method = 'OPTIONS') {
return 200;
}
有多種方式可以解決跨域問題（放鬆瀏覽器安全策略）
http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
這個是阮大神的總結
Cross-Origin Resource Sharing
CORS 是一種比較好的解決方案。這個模式就是用了預檢的請求。也就是正常請求前的 options請求。
跨域資源共享（CORS）是一種HTTP機制，使用HTTP請求頭定義源的權限。 使用CORS標頭，可以通知瀏覽器來自其他來源的資源有權訪問頁面上的資源。
例如
對站點的GET請求可能與聲明確切來源的Origin請求標頭一起發送（類似於document.domain）：
GET / HTTP/1.1
Host: www.example.com
(...)
Origin: http://example2.com
作爲迴應如果支持CORS的資源將發送Access-Control-Allow-Origin響應標頭：
HTTP/1.1 200 OK
(...)
Access-Control-Allow-Origin: http://example2.com
(...)
Access-Control-Allow-Origin標頭可以聲明單個源，源列表或通配符（*）。 當然，使用通配符會帶來很大的風險，但這取決於Web應用程序開發人員。
在options 請求後就會發送正常的請求。
options 請求
什麼是options 請求
1 獲取服務器支持的http 請求的方法。
2 檢查服務器的性能，例如 ajax 進行跨域請求時候的預檢測，需要向另外一個資源發送一個 HTTP OPTIONS的請求頭，用來判斷實際發送的請求是否安全。這裏的options 請求是瀏覽器的一種策略不是後端發起的
規範要求，對那些可能對服務器數據產生副作用的 HTTP 請求方法（特別是 GET 以外的 HTTP 請求，或者搭配某些 MIME 類型的 POST 請求），瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），從而獲知服務端是否允許該跨域請求。服務器確認允許之後，才發起實際的 HTTP 請求。
“需預檢的請求”要求必須首先使用 OPTIONS 方法發起一個預檢請求到服務器，以獲知服務器是否允許該實際請求。
當請求滿足下述任一條件時，即應首先發送預檢請求（使用OPTIONS）：
1、使用了下面任一 HTTP 方法：
PUT
DELETE
CONNECT
OPTIONS
TRACE
PATCH
2、人爲設置了對 CORS 安全的首部字段集合之外的其他首部字段。該集合爲：
Accept
Accept-Language
Content-Language
Content-Type (but note the additional requirements below)
DPR
Downlink
Save-Data
Viewport-Width
Width
3、Content-Type 的值不屬於下列之一:
application/x-www-form-urlencoded
multipart/form-data
text/plain