CORS也已經(jīng)成為主流的跨域解決方案，不過CORF也會引發(fā)CSRF，本文先分享第三方的一個前端工具箱全面展示那些瀏覽器版本支持CORS，由于各家瀏覽器廠商因為各自原因在不同的版本里支持的標(biāo)準(zhǔn)不同，這個工具小而美，可以清晰的比較不同版本瀏覽器前端技術(shù)兼容性對照表。

?

先看圖下面這個網(wǎng)站可以很方便的查看不同版本瀏覽器對CORS的支持力度，IE10，IE11，Chrome，Firefox，Safari太多了一個都少不了，基本涵蓋常見或者不常見的瀏覽器了，話說做前端真不容易啊。

https://caniuse.com/#search=cors

?如圖所示，這個圖表不是單純的顯示支持與不支持，還做了一些細(xì)分：

1 Does not support CORS for images in?<canvas>

2 Supported somewhat in IE8 and IE9 using the XDomainRequest object (but has?limitations)

3 Does not support CORS for?<video>?in?<canvas>: https://bugs.webkit.org/show_bug.cgi?id=135379

4 Does not support CORS for resources which redirect: https://bugzilla.mozilla.org/show_bug.cgi?id=1346749

CORS 跨域 實現(xiàn)思路及相關(guān)解決方案? ?寫的很好

其他例如CSS Grid Layout (level 1)

CSS Flexible Box Layout Module

ECMAScript 2015 (ES6)

也可以按不同的瀏覽器版本直接對比對不同技術(shù)規(guī)范的支持，比如H5選擇最新版本的IE11，Chrome，Firefox，Safari比較：

分至少部分支持和混合支持：

如果你遇到跨域問題還沒有使用CORS那么趕緊往下看。

同源政策

維基百科上關(guān)于同源策略的定義http://en.wikipedia.org/wiki/Same_origin_policy
同源策略是Web應(yīng)用程序安全模型中的一個重要概念。根據(jù)該策略，Web瀏覽器允許第一個Web頁面中包含的腳本訪問第二個Web頁面中的數(shù)據(jù)，但前提是兩個Web頁面具有相同的源。原點定義為URI方案，主機名和端口號的組合。此策略可防止一個頁面上的惡意腳本通過該頁面的文檔對象模型訪問另一個網(wǎng)頁上的敏感數(shù)據(jù)。

放寬同源政策（跨域解決方案）

在某些情況下，同源策略限制性太強，對使用多個子域的大型網(wǎng)站造成問題。首先，使用諸如使用片段標(biāo)識符或window.name屬性的許多變通方法來在駐留在不同域中的文檔之間傳遞數(shù)據(jù)。現(xiàn)代瀏覽器支持多種技術(shù)，以受控方式放寬同源策略：

1.document.domain屬性
如果兩個窗口（或框架）包含將域設(shè)置為相同值的腳本，則這兩個窗口將放寬同源策略，并且每個窗口可以與另一個窗口交互。例如，從orders.example.com和catalog.example.com加載的文檔中的協(xié)作腳本可能會將其document.domain屬性設(shè)置為“example.com”，從而使文檔看起來具有相同的來源并使每個文檔都能夠讀取另一個的屬性。設(shè)置此屬性會隱式將端口設(shè)置為null，大多數(shù)瀏覽器將從端口80或甚至未指定的端口進(jìn)行不同的解釋。要確保瀏覽器允許訪問，請設(shè)置兩個頁面的document.domain屬性。

2.跨源資源共享(CORS)
另一種放寬同源策略的技術(shù)是以跨源資源共享的名義標(biāo)準(zhǔn)化的。此標(biāo)準(zhǔn)使用新的Origin請求標(biāo)頭和新的Access-Control-Allow-Origin響應(yīng)標(biāo)頭擴(kuò)展HTTP。它允許服務(wù)器使用標(biāo)頭明確列出可能請求文件或使用通配符的起源，并允許任何站點請求文件。諸如Firefox 3.5，Safari 4和Internet Explorer 10之類的瀏覽器使用此標(biāo)頭來允許具有XMLHttpRequest的跨源HTTP請求，否則這些請求將被同源策略禁止。

3.跨文檔消息
另一種技術(shù)是跨文檔消息傳遞，允許來自一個頁面的腳本將文本消息傳遞到另一頁面上的腳本，而不管腳本來源如何。在Window對象上異步調(diào)用postMessage()方法會在該窗口中觸發(fā)“onmessage”事件，從而觸發(fā)任何用戶定義的事件處理程序。一個頁面中的腳本仍然無法直接訪問另一個頁面中的方法或變量，但它們可以通過此消息傳遞技術(shù)安全地進(jìn)行通信。

4.JSONP?
由于允許HTML<script>元素從其他域檢索和執(zhí)行內(nèi)容，因此頁面可以繞過同源策略，并通過加載返回JSONP有效負(fù)載的資源從不同的域接收J(rèn)SON數(shù)據(jù)。JSONP有效負(fù)載由預(yù)定義函數(shù)調(diào)用包裝的內(nèi)部JSON有效負(fù)載組成。當(dāng)瀏覽器加載腳本資源時，將調(diào)用指定的回調(diào)函數(shù)來處理包裝的JSON有效負(fù)載。

5.WebSockets?
現(xiàn)代瀏覽器將允許腳本連接到WebSocket地址而不應(yīng)用同源策略。但是，它們會在使用WebSocketURI時識別，并將Origin：標(biāo)頭插入到請求中，該請求指示請求連接的腳本的來源。為確保跨站點安全性，WebSocket服務(wù)器必須將標(biāo)頭數(shù)據(jù)與允許接收回復(fù)的原始白名單進(jìn)行比較。

?

?

為什么CORS很重要？

JavaScript和網(wǎng)絡(luò)編程多年來實現(xiàn)了跨越式發(fā)展，但同源政策仍然存在。這可以防止JavaScript跨域邊界發(fā)出請求，并產(chǎn)生了各種用于發(fā)出跨域請求的黑客攻擊。

CORS引入了一種標(biāo)準(zhǔn)機制，可供所有瀏覽器用于實現(xiàn)跨域請求。規(guī)范定義了一組標(biāo)頭，允許瀏覽器和服務(wù)器就允許（和不允許）哪些請求進(jìn)行通信。CORS通過為所有人提供API訪問來延續(xù)開放網(wǎng)絡(luò)的精神。

CORS與JSONP的使用目的相同，但是比JSONP更強大。

CORS與JSONP的比較可以看看https://stackoverflow.com/questions/12296910/so-jsonp-or-cors

為什么JSONP仍然是強制性的

為什么JSONP仍然是強制性的?

解決方案
使用JSONP是確保與舊瀏覽器的良好兼容性并處理錯誤配置的防火墻/代理問題的唯一解決方案。但是，CORS提供了正確錯誤處理的優(yōu)勢，因此我們不希望將自己局限于JSONP。

在我們的JavaScript客戶端的最新版本中，我們決定使用CORS來回退JSONP。在客戶端初始化時，我們檢查瀏覽器是否支持CORS，然后執(zhí)行OPTIONS查詢以檢查是否沒有阻止CORS請求的防火墻/代理。如果有任何錯誤，我們會回避JSONP。我們的JavaScript客戶端可以使用所有這些邏輯，而無需為客戶更改任何API /代碼。

擁有CORS支持以及JSONP上的自動回退是我們發(fā)現(xiàn)的最佳方式，可確保提供卓越的服務(wù)質(zhì)量并支持所有角落情況。如果您看到其他任何方式，我們非常歡迎您的反饋。

小結(jié)：JSONP只支持GET請求，CORS支持所有類型的HTTP請求。JSONP的優(yōu)勢在于支持老式瀏覽器，以及可以向不支持CORS的網(wǎng)站請求數(shù)據(jù)。

?

如何使CORS生效

為了使CORS正常生效，我們可以添加HTTP標(biāo)頭，允許服務(wù)器描述允許使用Web瀏覽器讀取該信息的一組源，并且對于不同類型的請求，我們必須添加不同的標(biāo)頭。該請求可以主要分為簡單請求和預(yù)檢請求。
簡單請求
請求不會觸發(fā)CORS預(yù)檢是所謂的簡單請求。一個簡單的請求應(yīng)滿足以下所有條件：

對于一個簡單的請求，要使CORS正常工作，Web服務(wù)器應(yīng)該設(shè)置一個HTTP頭：

Access-Control-Allow-Origin: *

設(shè)置此標(biāo)頭意味著任何域都可以訪問該資源。如果我們想限制到一個特定域，我們可以將其設(shè)置為：

Access-Control-Allow-Origin: http://specific.domain.example

預(yù)檢請求
預(yù)先請求的請求首先通過該OPTIONS方法向服務(wù)器發(fā)送HTTP請求，以確定實際請求（以下請求）是否可安全發(fā)送。預(yù)檢請求應(yīng)滿足以下所有條件：

對于預(yù)先發(fā)出的請求，要使CORS正常工作，Web服務(wù)器應(yīng)設(shè)置一些HTTP標(biāo)頭：

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 80000

CORS on Nginx

參考：https://enable-cors.org/server_nginx.html

#
# Wide-open CORS config for nginx
#
location / {if ($request_method = 'OPTIONS') {add_header 'Access-Control-Allow-Origin' '*';add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';## Custom headers and headers various browsers *should* be OK with but aren't#add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';## Tell client that this pre-flight info is valid for 20 days#add_header 'Access-Control-Max-Age' 1728000;add_header 'Content-Type' 'text/plain; charset=utf-8';add_header 'Content-Length' 0;return 204;}if ($request_method = 'POST') {add_header 'Access-Control-Allow-Origin' '*';add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';}if ($request_method = 'GET') {add_header 'Access-Control-Allow-Origin' '*';add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';}
}

?

防止CSRF攻擊

根據(jù)同源策略，既然允許跨源寫入，這就可能會導(dǎo)致安全問題引發(fā)CSRF攻擊 。

要防止CSRF攻擊，請在請求中檢查不可語量的令牌。例如，在HTTP參數(shù)中有一個隨機生成的令牌，表示名稱_csrf。

https://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work

CSRF解決方案參考：https://github.com/OWASP/CheatSheetSeries

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md?

需要保護(hù)的資源不受CSRF漏洞的影響

以下列表假定您沒有違反RFC2616第9.1.1節(jié)，通過使用GET請求進(jìn)行狀態(tài)更改操作。

注意：如果你違反任何理由，你也需要保護(hù)這些資源，其中大部分是使用默認(rèn)實現(xiàn)form?tag?[GET method]，href和src屬性。

• 使用POST表單標(biāo)簽
• Ajax / XHR調(diào)用

CSRF防御建議摘要

我們建議基于令牌的CSRF防御（有狀態(tài)/無狀態(tài)）作為緩解應(yīng)用程序中CSRF的主要防御。僅對于高度敏感的操作，我們還建議基于用戶交互的保護(hù)（重新認(rèn)證/一次性令牌，詳見6.5節(jié)）以及基于令牌的緩解。

作為一項縱深防御措施，請考慮從“深度緩解防御”部分實施一項緩解措施（您可以根據(jù)其中提到的問題選擇適合您的生態(tài)系統(tǒng)的緩解措施）。建議不要使用這些縱深防御緩解技術(shù)（不使用基于令牌的緩解）來減輕應(yīng)用程序中的CSRF。

初級防御技術(shù)

基于令牌的緩解

這種防御是減輕CSRF的最受歡迎和推薦的方法之一。它可以通過狀態(tài)（同步器令牌模式）或無狀態(tài)（基于加密/散列的令牌模式）來實現(xiàn)。請參閱第4.3節(jié)，了解如何減輕應(yīng)用程序中的登錄CSRF。對于所有緩解措施，隱含的是應(yīng)遵守一般安全原則

• 應(yīng)遵循強加密/ HMAC功能。

注意：您可以根據(jù)組織需求選擇任何算法。我們建議使用AES256-GCM進(jìn)行加密，使用SHA256 / 512進(jìn)行HMAC。

• 應(yīng)保持嚴(yán)格的密鑰輪換和令牌生存期策略。可以根據(jù)您的組織需求設(shè)置策略。可以在此處找到OWASP的通用密鑰管理指南。

?

參考：

什么是CORS（跨源資源共享）

HTTP訪問控制（CORS）

https://www.w3.org/TR/cors/

總結(jié)

以上是生活随笔為你收集整理的不同版本浏览器前端标准兼容性对照表以及CORS解决跨域和CSRF安全问题解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。