瀏覽器的同源策略是瀏覽器上為安全性考慮實施的非常重要的安全策略。
從一個域上加載的腳本不允許訪問另外一個域的文檔屬性。
舉個例子：比如一個惡意網站的頁面通過iframe嵌入了銀行的登錄頁面（二者不同源），
如果沒有同源限制，惡意網頁上的javascript腳本就可以在用戶登錄銀行的時候獲取用戶名和密碼。
何謂同源:URL由協議、域名、端口和路徑組成，如果兩個URL的協議、域名和端口相同，則表示它們同源。
在瀏覽器中，<script>、<img>、<iframe>、<link>等標簽都可以加載跨域資源，而不受同源限制，
但瀏覽器會限制腳本中發起的跨域請求（ajax請求能發起，能正常返回數據，只是瀏覽器拒絕了攔截了返回結果）。比如，使用 XMLHttpRequest 對象和Fetch發起 HTTP 請求就必須遵守同源策略。
Web 應用程序通過 XMLHttpRequest 對象或Fetch能且只能向同域名的資源發起 HTTP 請求，而不能向任何其它域名發起請求。
不允許跨域訪問並非是瀏覽器限制了發起跨站請求，而是跨站請求可以正常發起，但是返回結果被瀏覽器攔截了。
最好的例子是CSRF跨站攻擊原理，請求是發送到了后端服務器,無論是否設置允許跨域,
有些瀏覽器不允許從HTTPS跨域訪問HTTP，比如Chrome和Firefox，這些瀏覽器在請求還未發出的時候就會攔截請求,這是特例。
nginx是一台靜態資源服務器。當瀏覽器輸入網址，經過域名解析--尋找IP地址---到達nginx服務器，nginx返回給瀏覽器相應的html，css，js等等資源，一次會話完成。
如果有跨域資源ajax，nginx服務器需要對其進行配置轉發，再次請求該不同域處的服務器資源，這樣瀏覽器就能接受到該跨域資源。
解決方法：
我只關注兩種，其余的不想管，因為我們畢業出來，實際應用中就沒有了其余的方式。
一：代理服務器（需要請求的跨域資源，你的服務器幫你去請求到本服務器，然后以本服務器返回給你，就是本域返回給你跨域的信息，所以不是跨域的）
二：CORS，CORS全稱是"跨域資源共享"（Cross-origin resource sharing),CORS需要瀏覽器和服務器同時支持。目前，所有瀏覽器都支持該功能
(IE瀏覽器不能低於IE10)，因此，實現CORS通信的關鍵是服務器。只要服務器實現了CORS接口，就可以跨源通信。
當出現403跨域錯誤的時候 No 'Access-Control-Allow-Origin' header is present on the requested resource，需要給Nginx服務器配置響應的header參數：
一、 解決方案
只需要在Nginx的配置文件中配置以下參數：
location / { add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept"; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS"; }
二、 解釋
1. Access-Control-Allow-Origin
服務器默認是不被允許跨域的。給Nginx服務器配置Access-Control-Allow-Origin *后，表示服務器可以接受所有的請求源（Origin）,即接受所有跨域的請求。
2. Access-Control-Allow-Headers 是為了防止出現以下錯誤：
Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.
這個錯誤表示當前請求Content-Type的值不被支持。其實是我們發起了"application/json"的類型請求導致的。這里涉及到一個概念：預檢請求（preflight request）,請看下面"預檢請求"的介紹。
3. Access-Control-Allow-Methods 是為了防止出現以下錯誤：
Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.
發送"預檢請求"時，需要用到方法 OPTIONS ,所以服務器需要允許該方法。
三、 預檢請求（preflight request）
其實上面的配置涉及到了一個W3C標准：CROS,全稱是跨域資源共享 (Cross-origin resource sharing)，它的提出就是為了解決跨域請求的。
跨域資源共享(CORS)標准新增了一組 HTTP 首部字段，允許服務器聲明哪些源站有權限訪問哪些資源。另外，規范要求，對那些可能對服務器數據產生副作用的HTTP 請求方法（特別是 GET 以外的 HTTP 請求，或者搭配某些 MIME 類型的 POST 請求），瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），從而獲知服務端是否允許該跨域請求。服務器確認允許之后，才發起實際的 HTTP 請求。在預檢請求的返回中，服務器端也可以通知客戶端，是否需要攜帶身份憑證（包括 Cookies 和 HTTP 認證相關數據）。
其實Content-Type字段的類型為application/json的請求就是上面所說的搭配某些 MIME 類型的 POST 請求,CORS規定，
Content-Type不屬於以下MIME類型的，都屬於預檢請求：
application/x-www-form-urlencoded multipart/form-data text/plain所以 application/json的請求 會在正式通信之前，增加一次"預檢"請求，這次"預檢"請求會帶上頭部信息 Access-Control-Request-Headers: Content-Type：
OPTIONS /api/test HTTP/1.1
Origin: http://foo.example Access-Control-Request-Method: POST Access-Control-Request-Headers: Content-Type ... 省略了一些服務器回應時，返回的頭部信息如果不包含Access-Control-Request-Headers: Content-Type則表示不接受非默認的的Content-Type。即出現以下錯誤：
Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.
本文轉載自：https://www.cnblogs.com/wangpenghui522/p/6284355.html
和：http://blog.51cto.com/13523664/2060430