摘要：同源策略年，同源政策由公司引入瀏覽器。標(biāo)簽不受同源策略限制，但只能發(fā)起請(qǐng)求。這一行為使得不同域的特定文檔可以讀取該屬性值，因此可以繞過(guò)同源策略并使跨域消息通信成為可能。

現(xiàn)在cross-origin resource sharing（跨域資源共享，下簡(jiǎn)稱CORS）已經(jīng)十分普及，算上IE8的不標(biāo)準(zhǔn)兼容（XDomainRequest），各大瀏覽器基本都已支持，當(dāng)年為了前后端分離、iframe交互和第三方插件開發(fā)而頭疼跨域是時(shí)代已經(jīng)過(guò)去，但當(dāng)年為了跨域無(wú)所不用其極的風(fēng)騷操作卻依然值得學(xué)習(xí)。
本篇文章不是從實(shí)用的角度考量這些舊時(shí)代的跨域手段，而是更偏向理論的闡述，并引發(fā)對(duì)瀏覽器安全的思考，因?yàn)榭缬驅(qū)嶋H上也是各類攻擊的核心。
本人個(gè)人能力有限，歡迎大牛一起討論，批評(píng)指正。

1995年，同源政策由Netscape公司引入瀏覽器。目前，所有瀏覽器都實(shí)行這個(gè)安全策略。
核心是確保不同源提供的文件（資源）之間是相互獨(dú)立的。換句話說(shuō)，只有當(dāng)不同的文件腳本是由相同的域、端口、HTTP協(xié)議提供時(shí)，才沒(méi)有特殊的限制。特殊限制可以細(xì)分為兩個(gè)方面：

對(duì)象訪問(wèn)限制：主要體現(xiàn)在iframe，如果父子頁(yè)面的源是不同的，那就不可以訪問(wèn)對(duì)方的DOM方法和屬性（包括Cookie、LocalStorage和IndexDB等）。不同來(lái)源便拋出異常。

網(wǎng)絡(luò)訪問(wèn)限制：主要體現(xiàn)在AJAX請(qǐng)求，如果發(fā)起的請(qǐng)求目標(biāo)源與當(dāng)前頁(yè)面不同，瀏覽器就會(huì)限制了發(fā)起跨站請(qǐng)求，或攔截返回的請(qǐng)求。

一個(gè)表格看懂什么是同源？

至于為什么說(shuō)這是個(gè)安全策略？
這個(gè)就要提到cookie-session機(jī)制，眾所周知HTTP是無(wú)狀態(tài)協(xié)議，而服務(wù)器如何知曉用戶的登錄狀態(tài)？傳統(tǒng)上是使用了cookie-session這一機(jī)制，也就是服務(wù)器為每個(gè)訪問(wèn)者生成了一個(gè)session標(biāo)識(shí)，而session標(biāo)識(shí)會(huì)被服務(wù)器包含在應(yīng)答頭中返回，瀏覽器解析到應(yīng)答頭中的set-cookie就把這串session標(biāo)識(shí)保存到本地cookie中，利用cookie每次請(qǐng)求同一個(gè)域都會(huì)帶上的特性，服務(wù)器器就能知曉當(dāng)前的用戶登錄狀態(tài)。
所以如果讓瀏覽器向不同源發(fā)起請(qǐng)求，就會(huì)造成很大的危險(xiǎn)。比如用戶登錄了銀行的網(wǎng)站A，也就是說(shuō)A站已經(jīng)在瀏覽器留下了cookie，這時(shí)候用戶又訪問(wèn)了B站，如果能在B站頁(yè)面上發(fā)起A站的請(qǐng)求，就相當(dāng)于B站可以冒充用戶，在A站為所欲為。
由此可見，"同源策略"是必需的，否則cookie可以共享，互聯(lián)網(wǎng)就毫無(wú)安全可言了。

同源策略提出的時(shí)代還是傳統(tǒng)MVC架構(gòu)（jsp，asp）盛行的年代，那時(shí)候的頁(yè)面靠服務(wù)器渲染完成了大部分填充，內(nèi)容也比較簡(jiǎn)單，開發(fā)者也不會(huì)維護(hù)獨(dú)立的API工程，所以其實(shí)跨域的需求是比較少的。
新時(shí)代前后端的分離和第三方JSSDK的興起，我們才開始發(fā)現(xiàn)這個(gè)策略雖然大大提高了瀏覽器的安全性，但有時(shí)很不方便，合理的用途也受到影響。比如：

獨(dú)立的API工程部署為了方便管理使用了獨(dú)立的域名；

前端開發(fā)者本地調(diào)試需要使用遠(yuǎn)程的API；

第三方開發(fā)的JSSDK需要嵌入到別人的頁(yè)面中使用；

公共平臺(tái)的開放API。

于是乎，在沒(méi)有標(biāo)準(zhǔn)規(guī)范的時(shí)代，如何解決這些問(wèn)題的跨域方案就被紛紛提出，可謂百家爭(zhēng)鳴，其中不乏令人驚嘆的騷操作，這樣的極客精神依然值得我們敬佩和學(xué)習(xí)。

JSON-P是各類跨域方案中流行度較高的一個(gè)，現(xiàn)在在某些要兼容舊瀏覽器的環(huán)境下還會(huì)被使用，著名的jQuery也封裝其方法。請(qǐng)勿見名知義，名字中的P是padding“帶填充”的意思，這個(gè)方法在通信過(guò)程中使用的并不是普通的json，而是自帶填充功能的JavaScript腳本。
如何理解“自帶填充功能的JavaScript腳本”，看看下面的例子或許比較簡(jiǎn)單，如果一個(gè)js文件里這樣寫并被引入，則全局下就會(huì)有data對(duì)象，也就是說(shuō)利用js腳本的引入和解析可以用來(lái)傳遞數(shù)據(jù)，如果把js腳本換成函數(shù)運(yùn)行命令豈不是可以調(diào)用全局函數(shù)了。這就是JSON-P方法的核心思想，它填充的是全局函數(shù)的數(shù)據(jù)。

var data = {
  a: 1,
  b: 2
}

【PS】

// 定義回調(diào)函數(shù)
function getTheAnimal(data){
    var myAnimal = data.animal;
}
// 新建標(biāo)簽
var script = document.createElement("script");
script.type = "text/javascript";
// 常用的在url參數(shù)部分跟服務(wù)器約定號(hào)回調(diào)函數(shù)名
script.src = "http://demo.com/animal.json?callback=getTheAnimal";
document.getElementByTagName("head")[0].appendChild(script);
總結(jié)  
優(yōu)點(diǎn)：

簡(jiǎn)單，有現(xiàn)成的工具庫(kù)（jQuery）支持；
支持上古級(jí)別的瀏覽器（IE8-）。

缺點(diǎn)：

只能是GET方法；
受瀏覽器URL最大長(zhǎng)度2083字符限制；
無(wú)法調(diào)試，服務(wù)器錯(cuò)誤無(wú)法檢測(cè)到具體原因；
有CSRF的安全風(fēng)險(xiǎn)；
只能是異步，無(wú)法同步阻塞；
需要特殊接口支持，不能基于REST的API規(guī)范。

子域名代理
這個(gè)方法實(shí)際上是利用瀏覽器允許iframe內(nèi)的頁(yè)面只要是跟父頁(yè)面是同個(gè)一級(jí)域名下，就能被父頁(yè)面修改和調(diào)用的特點(diǎn)。也許你會(huì)疑問(wèn)，上面講同源策略的表格中很明確二級(jí)域名不同也是算不同源，這豈不矛盾了？  
這其實(shí)不矛盾，如果正常操作確實(shí)會(huì)被同源策略限制，但瀏覽器的document.domain允許網(wǎng)站將主機(jī)部分更改為原始值的后綴。這意味著，寄放在sub.example.com的頁(yè)面可以將它的源設(shè)置為example.com，但是并不能將其設(shè)置為alt.example.com或google.com。
【PS】這里有一個(gè)細(xì)節(jié)，父子頁(yè)面均要設(shè)置document.domain才能被互相訪問(wèn)，單一一個(gè)是無(wú)法跨域的。document.domain的特點(diǎn)：只能設(shè)置一次；只能更改域名部分，不能修改端口號(hào)和協(xié)議；重置源的端口為協(xié)議默認(rèn)端口。
原理及流程

新建一個(gè)子域，比如api.demo.com（頁(yè)面在主域名demo.com下）；
子域下需要一個(gè)代理文件proxy.html，設(shè)置其document.domain = "demo.com"，并可以包含發(fā)起ajax的工具；
所有API地址都是在api.demo.com；
把需要發(fā)請(qǐng)求的主域頁(yè)面設(shè)置其document.domain = "demo.com"；
新建iframe標(biāo)簽鏈接到代理頁(yè)；
當(dāng)iframe內(nèi)的子頁(yè)面就緒時(shí)，父頁(yè)面就可以使用子頁(yè)面發(fā)起ajax請(qǐng)求。


// 最簡(jiǎn)單的代理文件proxy.html


    
    

// 新建iframe
var iframe = document.createElement("iframe");
// 鏈接到代理頁(yè)
iframe.src = "http://api.demo.com/proxy.html";
// 代理頁(yè)就緒時(shí)觸發(fā)
iframe.onload = function(){
  // 由于代理頁(yè)已經(jīng)和父頁(yè)設(shè)置了相同的源，父的腳本可以調(diào)用代理頁(yè)的ajax工具；
  // 由于是在子頁(yè)面發(fā)起，其請(qǐng)求地址就跟子頁(yè)面同源了。
  iframe.contentWindow.jQuery.ajax({
    method: "POST",
    url: "http://api.demo.com/products",
    data: {
      product: id,
    },
    success: function(){
      document.body.removeChild(iframe);
      /*...*/
    }
  })
}
document.getElementsByTagName("head")[0].appendChild(iframe);
總結(jié)  
優(yōu)點(diǎn)：

可以發(fā)送任意類型的請(qǐng)求；
可以使用基于REST的API規(guī)范。

缺點(diǎn)：

不太適合第三方API，給第二方使用較麻煩；
iframe對(duì)瀏覽器性能影響較大；
無(wú)法使用非協(xié)議默認(rèn)端口的API。

模擬form表單
form表單的target屬性可以指定一個(gè)iframe，使主頁(yè)面不跳轉(zhuǎn)，而iframe內(nèi)跳轉(zhuǎn)，所以這個(gè)方法的核心就是利用表單提交，并在iframe中獲取數(shù)據(jù)。  
要訪問(wèn)iframe內(nèi)外頁(yè)面互訪也是必須設(shè)置同源，這點(diǎn)與子域代理是相似的；而iframe內(nèi)回調(diào)父頁(yè)面，又與JSON-P相似，可以說(shuō)是兩個(gè)思路的合體版。  
form表單提交后返回的是頁(yè)面，所以與JSON-P不同的是，返回的是包含了自帶填充功能的JavaScript腳本的頁(yè)面，說(shuō)起來(lái)有點(diǎn)繞，簡(jiǎn)單來(lái)說(shuō)就是把JSON-P返回的腳本放到一個(gè)html頁(yè)面里自運(yùn)行。  
相比子域代理的方法，它不需要代理頁(yè)。
【PS】form表單提交的特點(diǎn)就是會(huì)導(dǎo)致整個(gè)頁(yè)面跳轉(zhuǎn)，返回?cái)?shù)據(jù)是在新的頁(yè)面上，這樣自然不會(huì)產(chǎn)生跨域的問(wèn)題。
原理及流程

新建一個(gè)子域，比如api.demo.com（頁(yè)面在主域名demo.com下）；
所有API地址都是在api.demo.com；
把需要發(fā)請(qǐng)求的主域頁(yè)面設(shè)置其document.domain = "demo.com"；
先定義好父頁(yè)面上的回調(diào)函數(shù)；
新建iframe標(biāo)簽并指定名字；
新建表單form標(biāo)簽，指定target為剛才的iframe，并添加數(shù)據(jù)；
提交表單，iframe內(nèi)跳轉(zhuǎn)，其中自運(yùn)行腳本調(diào)用了父頁(yè)面的回調(diào)函數(shù)。


// 新建并隱藏iframe
var frame = document.createElement("iframe");
iframe.name = "post-review";
frame.style.display = "none";

// 新建表單
var form = document.createElement("form");
form.action = "http://api.demo.com/products";
form.method = "POST";
form.target = "post-review";
// 添加數(shù)據(jù)
var score = document.createElement("input");
score.name = "score";
score.value = "5";
// 添加數(shù)據(jù)
var message = document.createElement("input");
message.name = "message";
message.value = "hello world";
// 把數(shù)據(jù)加到表單
form.appendChild(score);
form.appendChild(message);
// 渲染iframe和表單
document.body.appendChild(frame);
document.body.appendChild(form);
// 提交表單發(fā)起請(qǐng)求
form.submit();
// 完成清理元素
document.body.removeChild(form);
document.body.removeChild(frame);
// 最簡(jiǎn)單返回html


    

總結(jié)  
由于這個(gè)方法是JSON-P與子域名代理的結(jié)合版，可以說(shuō)即擁有兩者的優(yōu)點(diǎn)，也保留了兩者一些缺點(diǎn)。  
優(yōu)點(diǎn)：

可以發(fā)送任意類型的請(qǐng)求；
不需要代理頁(yè)；
支持上古級(jí)別的瀏覽器（IE8-）。

缺點(diǎn)：

不太適合第三方API，給第二方使用較麻煩；
iframe對(duì)瀏覽器性能影響較大；
無(wú)法使用非協(xié)議默認(rèn)端口的API；
需要特殊接口支持，不能基于REST的API規(guī)范。

window.name
這方法利用了window.name的特性：一旦被賦值后，當(dāng)窗口被重定向到一個(gè)新的URL時(shí)不會(huì)改變它的值。這一行為使得不同域的特定文檔可以讀取該屬性值，因此可以繞過(guò)同源策略并使跨域消息通信成為可能。
【PS】例子里演示的是發(fā)起get請(qǐng)求，只要把請(qǐng)求地址直接寫到src里就行了。如果想要發(fā)起其他類型的請(qǐng)求，可以類比采用模擬的form的方式進(jìn)行改造。
原理及流程

新建iframe，使用iframe訪問(wèn)一個(gè)非同源的地址（發(fā)請(qǐng)求）；
當(dāng)頁(yè)面加載完成后，iframe內(nèi)腳本給window.name屬性賦值，這時(shí)父頁(yè)面還是不能讀取到子頁(yè)面的屬性（因?yàn)椴煌矗?/p>
iframe自身回調(diào)到一個(gè)同源的地址（可能只是個(gè)空白頁(yè)），這時(shí)候window.name沒(méi)有改變；
父頁(yè)面順利讀取window.name的值。


// 新建iframe
var iframe = document.createElement("iframe");
var body = document.getElementByTagName("body");
// 隱藏iframe并鏈接地址
iframe.style.display = "none";
iframe.src = "http://api.demo.com/server.html?id=1";
// 因?yàn)樾枰獌纱翁D(zhuǎn)，這里有個(gè)完成標(biāo)記
var done = fasle;
// 這里會(huì)觸發(fā)至少兩次，一次由于非同源是取不到值的。
iframe.onload = iframe.onreadystatechange = function(){
    if(! this.readyState && (iframe.readyState !== "complete" || done)){
        return;
    }
    console.log("Listening");
    var name = iframe.contentWindow.name;
    if(name){
        console.log(iframe.contentWindow.name);
        done = true;
    }
};
body.appendChild(iframe);
// 最簡(jiǎn)單返回html


    
    

總結(jié)  
優(yōu)點(diǎn)：

可以發(fā)送任意類型的請(qǐng)求；
不需要設(shè)置子域名。

缺點(diǎn)：

iframe對(duì)瀏覽器性能影響較大；
需要特殊接口支持，不能基于REST的API規(guī)范；
每當(dāng)你想要獲取一條新的消息時(shí)都不得不發(fā)起兩次網(wǎng)絡(luò)請(qǐng)求，網(wǎng)絡(luò)成本大；
需要準(zhǔn)備空白頁(yè)，對(duì)它的訪問(wèn)是無(wú)意義的，影響流量統(tǒng)計(jì)。

window.hash
這個(gè)方法利用了location的特性：不同域的頁(yè)面，可以寫不可讀。而只改變哈希部分（井號(hào)后面）不會(huì)導(dǎo)致頁(yè)面跳轉(zhuǎn)。也就是可以讓父、子頁(yè)面互相寫對(duì)方的location的哈希部分，進(jìn)行通訊。
原理及流程

新建iframe，使用iframe訪問(wèn)一個(gè)非同源的地址（發(fā)請(qǐng)求），參數(shù)里帶上父頁(yè)面url；
當(dāng)頁(yè)面加載完成后，iframe內(nèi)腳本設(shè)置父頁(yè)面的url并在哈希部分帶上數(shù)據(jù)；
父頁(yè)面的腳本循環(huán)檢查哈希值的變化，如果檢查到有值就取值并清空哈希值；

【PS】父頁(yè)面會(huì)循環(huán)檢查哈希是否改變來(lái)讀取值，因?yàn)檫@種降級(jí)方案的使用環(huán)境一般是不會(huì)有hashchange事件的。演示里是最簡(jiǎn)單的get方法，如果想要發(fā)起其他類型的請(qǐng)求，可以類比采用模擬的form的方式進(jìn)行改造，但記住不要丟失父頁(yè)面的url。

// 獲取當(dāng)前url
var url = window.location.href;
// 新建iframe
var iframe = document.createElement("iframe");
// 隱藏iframe并設(shè)置鏈接，把當(dāng)前url帶上
iframe.style.display = "none";
iframe.src = "http://api.demo.com/server.html?id=1&url=" + encodeURIComponent(url);

var body = document.getElementByTagName("body")[0];
body.appendChild(iframe);
// 循環(huán)監(jiān)聽處理
var listener = function(){
    // 讀取
    var hash = location.hash;
    // 還原
    if(hash && hash !== "#"){
        console.log(hash.replace("#", ""));
        window.loacation.href = url + "#";
    }
    // 繼續(xù)監(jiān)聽
    setTimeout(listener, 100);
};
listener();
// 最簡(jiǎn)單返回html


    
    

總結(jié)  
優(yōu)點(diǎn)：

可以發(fā)送任意類型的請(qǐng)求；
不需要設(shè)置子域名。

缺點(diǎn)：

iframe對(duì)瀏覽器性能影響較大；
需要特殊接口支持，不能基于REST的API規(guī)范；
循環(huán)檢查哈希需要消耗性能；
返回?cái)?shù)據(jù)受瀏覽器URL最大長(zhǎng)度2083字符限制。

現(xiàn)代的標(biāo)準(zhǔn)
W3C的標(biāo)準(zhǔn)化跨域方案，讓現(xiàn)代瀏覽器跨域已經(jīng)不是什么復(fù)雜的事。這部分網(wǎng)上資料已經(jīng)很多，這里就只是簡(jiǎn)單介紹。
CORS
CORS是一個(gè)W3C標(biāo)準(zhǔn)，全稱是"跨域資源共享"（Cross-origin resource sharing）。  
它允許瀏覽器向跨源服務(wù)器，發(fā)出XMLHttpRequest請(qǐng)求，從而克服了AJAX只能同源使用的限制。  
CORS參考文檔  
跨域資源共享 CORS 詳解
postMessage
H5的window.postMessage為瀏覽器帶來(lái)了一個(gè)安全的?；谑录南pi。  
只要是window對(duì)象，基本都可以使用這個(gè)方法，也就是說(shuō)window.name、window.hash這類風(fēng)騷的操作都已成為降級(jí)方案。  
postMessage參考文檔
安全問(wèn)題
上述的各類非標(biāo)準(zhǔn)的騷操作，都算是對(duì)同源策略的破解辦法，在方便開發(fā)者完成跨域目的的同時(shí)，各類惡意的攻擊者也自然會(huì)利用這些方案為非作歹。  
其中子域名代理的風(fēng)險(xiǎn)最低，因?yàn)樾枰?wù)器設(shè)置特定的子域名，也就是已經(jīng)是兩個(gè)源的協(xié)商結(jié)果，一般黑客是難以模擬的。  
風(fēng)險(xiǎn)最高的要算JSON-P的方案，因?yàn)檫@是任何客戶端都可隨意使用的辦法，CSRF攻擊的核心也是利用了特定標(biāo)簽的跨域性發(fā)起請(qǐng)求，所以JSON-P最好用在無(wú)用戶狀態(tài)的低安全性API上。