前言：對于跨域請求，很早之前就有去了解過，但因?yàn)橐恢标P(guān)注的都是服務(wù)器后端開發(fā)，故也就僅僅停留在概念的理解上而沒有機(jī)會在實(shí)際開發(fā)場景中接觸得到。最近在公司的開發(fā)任務(wù)中，需要接觸到 Ajax 跨域請求，由于之前沒有遇到過類似的問題，在開發(fā)過程中遇到不少困難，也查閱了不少資料和博客。在這過程中收獲了不少，故特意寫下以下文章總結(jié)，如果文章有什么不足之處，還望各位指出。

什么是跨域請求

概述

在 HTML 中，<a>, <form>, <img>, <script>, <iframe>, <link> 等標(biāo)簽以及 Ajax 都可以指向一個資源地址，而所謂的跨域請求就是指：當(dāng)前發(fā)起請求的域與該請求指向的資源所在的域不一樣。這里的域指的是這樣的一個概念：我們認(rèn)為若協(xié)議 + 域名 + 端口號均相同，那么就是同域。

舉個例子：假如一個域名為aaa.cn的網(wǎng)站，它發(fā)起一個資源路徑為aaa.cn/books/getBookInfo的 Ajax 請求，那么這個請求是同域的，因?yàn)橘Y源路徑的協(xié)議、域名以及端口號與當(dāng)前域一致（例子中協(xié)議名默認(rèn)為http，端口號默認(rèn)為80）。但是，如果發(fā)起一個資源路徑為bbb.com/pay/purchase的 Ajax 請求，那么這個請求就是跨域請求，因?yàn)橛虿灰恢?，與此同時由于安全問題，這種請求會受到同源策略限制。

跨域請求的安全問題

通常，瀏覽器會對上面提到的跨域請求作出限制。瀏覽器之所以要對跨域請求作出限制，是出于安全方面的考慮，因?yàn)榭缬蛘埱笥锌赡鼙徊环ǚ肿永脕戆l(fā)動 CSRF攻擊。

CSRF攻擊：

CSRF（Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。CSRF攻擊者在用戶已經(jīng)登錄目標(biāo)網(wǎng)站之后，誘使用戶訪問一個攻擊頁面，利用目標(biāo)網(wǎng)站對用戶的信任，以用戶身份在攻擊頁面對目標(biāo)網(wǎng)站發(fā)起偽造用戶操作的請求，達(dá)到攻擊目的。

CSRF 攻擊的原理大致描述如下：有兩個網(wǎng)站，其中A網(wǎng)站是真實(shí)受信任的網(wǎng)站，而B網(wǎng)站是危險網(wǎng)站。在用戶登陸了受信任的A網(wǎng)站是，本地會存儲A網(wǎng)站相關(guān)的Cookie，并且瀏覽器也維護(hù)這一個Session會話。這時，如果用戶在沒有登出A網(wǎng)站的情況下訪問危險網(wǎng)站B，那么危險網(wǎng)站B就可以模擬發(fā)出一個對A網(wǎng)站的請求（跨域請求）對A網(wǎng)站進(jìn)行操作，而在A網(wǎng)站的角度來看是并不知道請求是由B網(wǎng)站發(fā)出來的（Session和Cookie均為A網(wǎng)站的），這時便成功發(fā)動一次CSRF 攻擊。

因而 CSRF 攻擊可以簡單理解為：攻擊者盜用了你的身份，以你的名義發(fā)送而已請求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號，甚至于購買商品，虛擬貨幣轉(zhuǎn)賬......造成的問題包括：個人隱私泄露以及財產(chǎn)安全。

因此，大多數(shù)瀏覽器都會跨域請求作出限制，這是從瀏覽器層面上的對 CSRF 攻擊的一種防御，但是需要注意的是在復(fù)雜的網(wǎng)絡(luò)環(huán)境中借助瀏覽器來防御 CSRF 攻擊并不足夠，還需要從服務(wù)端或者客戶端方面入手防御。

同源策略(Same-origin Policy)

概述

· 同源策略是 Netscape 提出的一個著名的安全策略

· 同源策略是瀏覽器最核心最基礎(chǔ)的安全策略

· 現(xiàn)在所有的可支持 Javascript 的瀏覽器都會使用這個策略

· web構(gòu)建在同源策略基礎(chǔ)之上，瀏覽器對非同源腳本的限制措施是對同源策略的具體實(shí)現(xiàn)

同源策略的含義

· DOM 層面的同源策略：限制了來自不同源的”Document”對象或 JS 腳本，對當(dāng)前“document”對象的讀取或設(shè)置某些屬性

· Cookie和XMLHttprequest層面的同源策略：禁止 Ajax 直接發(fā)起跨域HTTP請求（其實(shí)可以發(fā)送請求，結(jié)果被瀏覽器攔截，不展示），同時 Ajax 請求不能攜帶與本網(wǎng)站不同源的 Cookie。

· 同源策略的非絕對性：<script><img><iframe><link><video><audio>等帶有src屬性的標(biāo)簽可以從不同的域加載和執(zhí)行資源。

· 其他插件的同源策略：flash、java applet、silverlight、googlegears等瀏覽器加載的第三方插件也有各自的同源策略，只是這些同源策略不屬于瀏覽器原生的同源策略，如果有漏洞則可能被黑客利用，從而留下XSS攻擊的后患

同源的具體含義

· 域名、協(xié)議、端口有一個不同就不是同源，三者均相同，這兩個網(wǎng)站才是同源

跨域解決方法

雖然在安全層面上同源限制是必要的，但有時同源策略會對我們的合理用途造成影響，為了避免開發(fā)的應(yīng)用受到限制，有多種方式可以繞開同源策略，下面介紹的是經(jīng)常使用的 JSONP, CORS 方法。

JSONP

原理：

· JSONP 是一種非官方的跨域數(shù)據(jù)交互協(xié)議

· JSONP 本質(zhì)上是利用 <script><img><iframe> 等標(biāo)簽不受同源策略限制，可以從不同域加載并執(zhí)行資源的特性，來實(shí)現(xiàn)數(shù)據(jù)跨域傳輸。

· JSONP由兩部分組成：回調(diào)函數(shù)和數(shù)據(jù)?；卣{(diào)函數(shù)是當(dāng)響應(yīng)到來時應(yīng)該在頁面中調(diào)用的函數(shù)，而數(shù)據(jù)就是傳入回調(diào)函數(shù)中的JSON數(shù)據(jù)。

· JSONP 的理念就是，與服務(wù)端約定好一個回調(diào)函數(shù)名，服務(wù)端接收到請求后，將返回一段 Javascript，在這段 Javascript 代碼中調(diào)用了約定好的回調(diào)函數(shù)，并且將數(shù)據(jù)作為參數(shù)進(jìn)行傳遞。當(dāng)網(wǎng)頁接收到這段 Javascript 代碼后，就會執(zhí)行這個回調(diào)函數(shù)，這時數(shù)據(jù)已經(jīng)成功傳輸?shù)娇蛻舳肆恕?/span>

示例：

首先當(dāng)前頁面中聲明有這樣的一個函數(shù)，它將作為 JSONP 的回調(diào)函數(shù)處理作為函數(shù)參數(shù)傳入的數(shù)據(jù)

然后，我們就可以借助 <script><img><iframe> 等標(biāo)簽可以引入不同域資源的特性，將需要發(fā)送的請求的路徑作為src參數(shù)，其中需要注意的是：需要告知服務(wù)端回調(diào)函數(shù)的函數(shù)名。

這時服務(wù)端在返回數(shù)據(jù)的時候，就會返回一端 Javascript 代碼，在 Javascript代碼中調(diào)用了回調(diào)函數(shù)，并且需要返回的數(shù)據(jù)作為回調(diào)函數(shù)的參數(shù)

最后頁面成功加載了剛才指定路徑的資源后，將會執(zhí)行該 Javascript 代碼，dosomething函數(shù)將執(zhí)行，這時一次跨域請求完成。

另外，如果頁面引入了 jQuery，那么可以通過它封裝的方法很方便的實(shí)現(xiàn)JSONP操作了

優(yōu)缺點(diǎn)：

JSONP 的優(yōu)點(diǎn)是：它不像XMLHttpRequest對象實(shí)現(xiàn)的Ajax請求那樣受到同源策略的限制；它的兼容性更好，在更加古老的瀏覽器中都可以運(yùn)行。

JSONP 的缺點(diǎn)是：它只支持 GET 請求，而不支持 POST 請求等其他類型的 HTTP 請求

CORS

介紹

跨源資源共享 Cross-Origin Resource Sharing(CORS) 是一個新的 W3C 標(biāo)準(zhǔn)，它新增的一組HTTP首部字段，允許服務(wù)端其聲明哪些源站有權(quán)限訪問哪些資源。換言之，它允許瀏覽器向聲明了 CORS 的跨域服務(wù)器，發(fā)出 XMLHttpReuest 請求，從而克服 Ajax 只能同源使用的限制。

另外，規(guī)范也要求對于非簡單請求，瀏覽器必須首先使用 OPTION 方法發(fā)起一個預(yù)檢請求(preflight request)，從而獲知服務(wù)端是否允許該跨域請求，在服務(wù)器確定允許后，才發(fā)起實(shí)際的HTTP請求。

HTTP 協(xié)議 Header 簡析

下面對 CORS 中新增的 HTTP 首部字段進(jìn)行簡析：

· Access-Control-Allow-Origin

響應(yīng)首部中可以攜帶這個頭部表示服務(wù)器允許哪些域可以訪問該資源，其語法如下：

其中，origin 參數(shù)的值指定了允許訪問該資源的外域 URI。對于不需要攜帶身份憑證的請求，服務(wù)器可以指定該字段的值為通配符，表示允許來自所有域的請求。

· Access-Control-Allow-Methods

該首部字段用于預(yù)檢請求的響應(yīng)，指明實(shí)際請求所允許使用的HTTP方法。其語法如下：

· Access-Control-Allow-Headers

該首部字段用于預(yù)檢請求的響應(yīng)。指明了實(shí)際請求中允許攜帶的首部字段。其語法如下：

· Access-Control-Max-Age

該首部字段用于預(yù)檢請求的響應(yīng)，指定了預(yù)檢請求能夠被緩存多久，其語法如下：

· Access-Control-Allow-Credentials

該字段可選。它的值是一個布爾值，表示是否允許發(fā)送Cookie。默認(rèn)情況下，Cookie不包括在CORS請求之中。設(shè)為true，即表示服務(wù)器明確許可，Cookie可以包含在請求中，一起發(fā)給服務(wù)器。其語法如下：

另外，如果要把 Cookie 發(fā)送到服務(wù)器，除了服務(wù)端要帶上Access-Control-Allow-Credentials首部字段外，另一方面請求中也要帶上withCredentials屬性。

但是需要注意的是：如果需要在 Ajax 中設(shè)置和獲取 Cookie，那么Access-Control-Allow-Origin首部字段不能設(shè)置為* ，必須設(shè)置為具體的 origin 源站。

· Origin

該首部字段表明預(yù)檢請求或?qū)嶋H請求的源站。不管是否為跨域請求，Origin字段總是被發(fā)送。其語法如下：

· Access-Control-Request-Method

該首部字段用于預(yù)檢請求。其作用是，將實(shí)際請求所使用的 HTTP 方法告訴服務(wù)器。其語法如下：

· Access-Control-Request-Headers

該首部字段用于預(yù)檢請求。其作用是，將實(shí)際請求所攜帶的首部字段告訴服務(wù)器。其語法如下：

示例

假設(shè)我們在 bbb.cn 域名下，發(fā)送一個 Ajax 請求到 aaa.cn 域名，其路徑如下：http://aaa.cn/localserver/api/corsTest 。由于同源策略，這樣的 Ajax 請求將會被瀏覽器所攔截，得到下面的信息：

若想能夠發(fā)送跨域請求，我們只需要在服務(wù)器的響應(yīng)中配置適當(dāng)?shù)?/span>CORS HTTP 首部字段就可以了，例如可以加入以下的首部字段：

此時，Ajax請求就可以順利的發(fā)送和接收了，對于在 Java Web 項(xiàng)目中，如何在 Servlet 或這 Spring MVC 中配置 CORS

與 JSONP 的比較

· JSONP 只能實(shí)現(xiàn) GET 請求，而 CORS 支持所有類型的 HTTP 請求

· 使用 CORS ，開發(fā)者可以是使用普通的 XMLHttpRequest 發(fā)起請求和獲取數(shù)據(jù)，比起 JSONP 有更好的錯誤處理

· 雖然絕大多數(shù)現(xiàn)代的瀏覽器都已經(jīng)支持 CORS，但是 CORS 的兼容性比不上 JSONP，一些比較老的瀏覽器只支持 JSONP