?
本文檔使用 PHP中文網手冊 發(fā)布
當資源請求來自不同域，協議或端口的資源時，資源會發(fā)出跨源HTTP請求。例如，http://domain-a.com<img> src提供的HTML頁面提出了http://domain-b.com/image.jpg的請求。今天網絡上的許多頁面都會加載資源，如來自不同域的CSS樣式表，圖像和腳本。
出于安全原因，瀏覽器限制從腳本內發(fā)起的跨源HTTP請求。例如，XMLHttpRequest并且取遵循同源策略。因此，使用XMLHttpRequest或提取 的Web應用程序只能向自己的域發(fā)出HTTP請求。為了改進Web應用程序，開發(fā)人員要求瀏覽器供應商允許跨域請求。
跨源資源共享（CORS）機制為Web服務器提供跨域訪問控制，從而實現安全的跨域數據傳輸。現代瀏覽器在API容器中使用CORS（例如XMLHttpRequest或Fetch）來緩解跨源HTTP請求的風險。
本文適用于Web管理員，服務器開發(fā)人員和前端開發(fā)人員?，F代瀏覽器處理跨源共享的客戶端組件，包括標頭和策略實施。但是這個新標準意味著服務器必須處理新的請求和響應頭文件。另一篇關于服務器開發(fā)人員從服務器角度討論跨源共享的文章（使用PHP代碼片段）是補充閱讀。
這種跨源共享標準用于為以下項目啟用跨站點HTTP請求：
如上所述，以跨站點的方式調用
XMLHttpRequest或提取 API。Web字體（用于
@font-faceCSS內的跨域字體使用），以便服務器可以部署TrueType字體，這些字體只能跨站點加載并由允許這樣做的網站使用。WebGL紋理。
使用繪制到畫布的圖像/視頻幀
drawImage。樣式表（用于CSSOM訪問）。
腳本（用于非靜音例外）。
本文是跨源資源共享的一般性討論，并包括對必要HTTP標頭的討論。
總覽
跨源資源共享標準的工作原理是添加新的HTTP標頭，允許服務器描述允許使用Web瀏覽器讀取該信息的一組原點。此外，對于可能對服務器數據產生副作用的HTTP請求方法（特別是針對除特定MIME類型之外的HTTP方法GET或針對POST某些MIME類型使用的HTTP方法），規(guī)范要求瀏覽器“預檢”請求，請求來自服務器與HTTP OPTIONS請求方法，然后，在從服務器獲得“批準”后，使用實際的HTTP請求方法發(fā)送實際請求。服務器還可以通知客戶端“憑證”（包括Cookie和HTTP認證數據）是否應該隨請求一起發(fā)送。
后續(xù)章節(jié)討論方案，并提供所使用的HTTP標頭的細目。
訪問控制場景的示例
在這里，我們提供了三個場景來說明跨源資源共享如何工作。所有這些示例都使用該XMLHttpRequest對象，該對象可用于在任何支持的瀏覽器中進行跨站點調用。
這些部分包含的JavaScript代碼片段（以及正確處理這些跨站點請求的服務器代碼的運行實例）可以在http://arunranga.com/examples/access-control/中找到“實際操作” ，并且將在支持跨站點的瀏覽器中工作XMLHttpRequest。
從服務器的角度討論跨源資源共享（包括PHP代碼片段）可以在服務器端訪問控制（CORS）文章中找到。
簡單的請求
有些請求不會觸發(fā)CORS預檢。這些在本文中被稱為“簡單請求”，盡管Fetch規(guī)范（它定義了CORS）不使用該術語。不會觸發(fā)CORS預檢的請求（所謂的“簡單請求”）是滿足以下所有條件的請求：
唯一允許的方法是：
GETHEADPOST除了由用戶代理自動設置的標頭（例如，
Connection，User-Agent，或任何與所述抓取規(guī)格為“禁止的標題名稱”定義名稱其它標題的），其允許被手動設置僅標頭是那些Fetch規(guī)范將其定義為“CORS安全列表請求標頭”，它們是：AcceptAccept-LanguageContent-LanguageContent-Type（但請注意下面的附加要求）Last-Event-IDDPRDownlinkSave-DataViewport-WidthWidthContent-Type標題的唯一允許值是：application/x-www-form-urlencodedmultipart/form-datatext/plain沒有事件偵聽器
XMLHttpRequestUpload在請求中使用的任何對象上注冊。ReadableStream請求中沒有使用對象。
注意：這些是與Web內容已經發(fā)布的相同類型的跨站點請求，并且除非服務器發(fā)送適當的標頭，否則不會向請求者發(fā)布響應數據。因此，防止跨站點請求偽造的站點對HTTP訪問控制毫無新意。
注：允許在WebKit每日和Safari瀏覽器技術預覽地方上的值的額外限制Accept，Accept-Language和Content-Language頭。如果任何這些頭文件具有“非標準”值，則WebKit / Safari不會將該請求視為符合“簡單請求”的條件。除了以下WebKit錯誤之外，WebKit / Safari認為這些標頭的“非標準”值沒有記錄：對非標準CORS安全列表的請求標頭需要預檢Accept，Accept-Language和Content-Language，允許逗號，簡單CORS的Accept-Language和Content-Language請求標題，以及在簡單的CORS請求中切換到黑名單模型以獲取受限制的Accept標頭。沒有其他瀏覽器實現這些額外的限制，因為它們不是規(guī)范的一部分。
例如，假設域上的網頁內容http://foo.example希望調用域上的內容http://bar.other。這種代碼可以在部署在foo.example上的JavaScript中使用：
var invocation = new XMLHttpRequest();var url = 'http://bar.other/resources/public-data/'; function callOtherDomain() { if(invocation) {
invocation.open('GET', url, true);
invocation.onreadystatechange = handler;
invocation.send();
}}這將導致客戶端和服務器之間的簡單交換，使用CORS頭來處理權限：
讓我們看看在這種情況下瀏覽器將發(fā)送到服務器的內容，然后讓我們看看服務器如何響應：
GET /resources/public-data/ HTTP/1.1Host: bar.other User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: keep-alive Referer: http://foo.example/examples/access-control/simpleXSInvocation.html Origin: http://foo.example HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 00:23:53 GMT Server: Apache/2.0.61 Access-Control-Allow-Origin: * Keep-Alive: timeout=2, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/xml [XML Data]
1 - 10行發(fā)送標題。這里需要注意的主要HTTP請求頭是Origin上面第10行的頭，表示調用來自域上的內容http://foo.example。
第13 - 22行顯示了域上服務器的HTTP響應http://bar.other。作為響應，服務器發(fā)回一個Access-Control-Allow-Origin頭部，如上面第16行所示。使用Origin頭部和Access-Control-Allow-Origin顯示訪問控制協議的最簡單的用法。在這種情況下，服務器回應一個Access-Control-Allow-Origin: *，這意味著資源可以通過任何域以跨站點方式訪問。如果資源所有者http://bar.other希望將資源的訪問限制為僅來自請求的資源http://foo.example，則他們將發(fā)回：
Access-Control-Allow-Origin: http://foo.example
請注意，現在除了http://foo.example（由請求中的ORIGIN：標頭標識的，如上面的第10行）之外，沒有任何域可以以跨站點方式訪問資源。該Access-Control-Allow-Origin頭應包含在請求的發(fā)送的值Origin頭。
預先請求的請求
與上面討論的“簡單請求”不同，“preflighted”請求首先通過OPTIONS方法向另一個域上的資源發(fā)送HTTP請求，以確定實際請求是否安全發(fā)送?？缯菊埱笫沁@樣預檢的，因為它們可能會影響用戶數據。
特別是，如果滿足以下任一條件，則會請求一個請求：
如果請求使用以下任何一種方法：
PUTDELETECONNECTOPTIONSTRACEPATCH或者，如果，除了由用戶代理自動設置的標頭（例如，
Connection，User-Agent，或任何與所述抓取規(guī)格為“禁止的標題名稱”中定義的名稱其它頭的），該請求包括比其他任何頭那些Fetch規(guī)范將其定義為“CORS安全列表請求標頭”，它們是：AcceptAccept-LanguageContent-LanguageContent-Type（但請注意下面的附加要求）Last-Event-IDDPRDownlinkSave-DataViewport-WidthWidth或者，如果該
Content-Type頭具有比其他如下的值：application/x-www-form-urlencodedmultipart/form-datatext/plain或者，如果
XMLHttpRequestUpload在請求中使用的對象上注冊了一個或多個事件偵聽器。或者如果
ReadableStream請求中使用了對象。
注：允許在WebKit每日和Safari瀏覽器技術預覽地方上的值的額外限制Accept，Accept-Language和Content-Language頭。如果這些標頭中的任何一個具有“非標準”值，WebKit / Safari會預檢請求。除了以下WebKit錯誤之外，WebKit / Safari認為這些標頭的“非標準”值沒有記錄：對非標準CORS安全列表的請求標頭需要預檢Accept，Accept-Language和Content-Language，允許逗號，簡單CORS的Accept-Language和Content-Language請求標題，以及在簡單的CORS請求中切換到黑名單模型以獲取受限制的Accept標頭。沒有其他瀏覽器實現這些額外的限制，因為它們不是規(guī)范的一部分。
以下是一個將被預沖的請求示例。
var invocation = new XMLHttpRequest();var url = 'http://bar.other/resources/post-here/';var body = '<?xml version="1.0"?><person><name>Arun</name></person>'; function callOtherDomain(){ if(invocation) {
invocation.open('POST', url, true);
invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
invocation.setRequestHeader('Content-Type', 'application/xml');
invocation.onreadystatechange = handler;
invocation.send(body);
}}......在上面的示例中，第3行創(chuàng)建了一個XML主體，以便POST在第8行中發(fā)送請求。另外，在第9行中，設置了一個“自定義”（非標準）HTTP請求標頭X-PINGOTHER: pingpong。這樣的頭文件不是HTTP / 1.1協議的一部分，但通常對Web應用程序有用。由于請求使用Content-Type application/xml，并且由于設置了自定義標頭，所以該請求是預檢的。
（注意：如下所述，實際的POST請求不包含Access-Control-Request- *標題;它們僅用于OPTIONS請求。）
我們來看看客戶端和服務器之間的完整交換。第一個交換是預檢請求/響應：
OPTIONS /resources/post-here/ HTTP/1.1Host: bar.other User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: keep-alive Origin: http://foo.example Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 01:15:39 GMT Server: Apache/2.0.61 (Unix) Access-Control-Allow-Origin: http://foo.example Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type Access-Control-Max-Age: 86400 Vary: Accept-Encoding, Origin Content-Encoding: gzip Content-Length: 0 Keep-Alive: timeout=2, max=100 Connection: Keep-Alive Content-Type: text/plain
預檢請求完成后，發(fā)送真正的請求：
POST /resources/post-here/ HTTP/1.1Host: bar.other User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: keep-alive X-PINGOTHER: pingpong Content-Type: text/xml; charset=UTF-8 Referer: http://foo.example/examples/preflightInvocation.html Content-Length: 55 Origin: http://foo.example Pragma: no-cache Cache-Control: no-cache <?xml version="1.0"?><person><name>Arun</name></person> HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 01:15:40 GMT Server: Apache/2.0.61 (Unix) Access-Control-Allow-Origin: http://foo.example Vary: Accept-Encoding, Origin Content-Encoding: gzip Content-Length: 235 Keep-Alive: timeout=2, max=99 Connection: Keep-Alive Content-Type: text/plain [Some GZIP'd payload]
上面的第1-12行代表使用該OPTIONS方法的預檢請求。瀏覽器根據上述JavaScript代碼片段使用的請求參數確定需要發(fā)送該消息，以便服務器可以響應以實際請求參數發(fā)送請求是否可接受。OPTIONS是一個HTTP / 1.1方法，用于確定來自服務器的更多信息，并且是一種安全的方法，這意味著它不能用于更改資源。請注意，除OPTIONS請求外，還會發(fā)送另外兩個請求標頭（分別為第10行和第11行）：
Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type
Access-Control-Request-Method報頭通知服務器作為預檢請求被發(fā)送的實際請求時，它將被與發(fā)送的一部分POST請求方法。該Access-Control-Request-Headers頭通知服務器發(fā)送實際的請求時，它將被發(fā)送的X-PINGOTHER和Content-Type自定義頁眉。服務器現在有機會確定它是否希望在這種情況下接受請求。
上面的第14-26行是服務器發(fā)回的響應，表明請求方法（POST）和請求頭（X-PINGOTHER）是可接受的。具體來說，我們來看第17-20行：
Access-Control-Allow-Origin: http://foo.example Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type Access-Control-Max-Age: 86400
服務器響應Access-Control-Allow-Methods，并說POST，GET和OPTIONS是可行的方法來查詢相關資源。請注意，此標頭與Allow響應標頭相似，但在訪問控制的上下文中嚴格使用。
服務器也發(fā)送Access-Control-Allow-Headers一個值為“ X-PINGOTHER, Content-Type”，確認這些是允許的頭部與實際的請求一起使用。像Access-Control-Allow-Methods，Access-Control-Allow-Headers是可以接受的報頭的逗號分隔的列表。
最后，Access-Control-Max-Age給出以秒為單位的值，可以緩存對預檢請求的響應多長時間，而不發(fā)送其他預檢請求。在這種情況下，86400秒是24小時。請注意，每個瀏覽器都有一個最大內部值，當該Access-Control-Max-Age值較大時優(yōu)先。
預先發(fā)送的請求和重定向
大多數瀏覽器目前不支持預先發(fā)送的請求的重定向。如果針對預先發(fā)送的請求發(fā)生重定向，則大多數當前瀏覽器將報告如下的錯誤消息。
該請求被重定向到“ https://example.com/foo ”，該請求被禁止用于需要預檢的跨請求請求。請求需要預檢，不允許跟蹤跨源重定向
CORS協議最初需要這種行為，但后來被更改為不再需要它。但是，大多數瀏覽器尚未實現此更改并仍顯示最初所需的行為。
因此，除非瀏覽器趕上規(guī)范，否則您可以通過執(zhí)行以下一項或兩項操作來解決此限制：
更改服務器端行為以避免預檢和/或避免重定向 - 如果您有控制服務器的請求正在進行
請更改請求，使其不會產生印前檢查
但是如果不能做出這些改變，那么另一種可能的方式就是：
做一個簡單的請求來確定（使用Response.url來獲取API，或者使用XHR.responseURL來確定真正的預發(fā)光請求最終會到達哪個URL）。
使用從Response.url或XMLHttpRequest.responseURL獲取的URL 在第一步中創(chuàng)建另一個請求（“真實”請求）。
但是，如果請求是由于請求中存在Authorization標題而觸發(fā)預檢的請求，則無法使用上述步驟解決限制。除非您可以控制正在進行請求的服務器，否則您將無法徹底解決此問題。
請求憑證
由兩個暴露的最有趣的功能XMLHttpRequest或獲取和CORS是使知道HTTP Cookie和HTTP認證信息的“持證”請求的能力。默認情況下，在跨站點XMLHttpRequest或Fetch調用中，瀏覽器不會發(fā)送憑據。調用時，必須在XMLHttpRequest對象或Request構造函數上設置特定的標志。
在此示例中，最初加載的內容http://foo.example向http://bar.other設置了Cookie 的資源發(fā)出簡單的GET請求。foo.example上的內容可能包含JavaScript，如下所示：
var invocation = new XMLHttpRequest();var url = 'http://bar.other/resources/credentialed-content/'; function callOtherDomain(){ if(invocation) {
invocation.open('GET', url, true);
invocation.withCredentials = true;
invocation.onreadystatechange = handler;
invocation.send();
}}第7行顯示了XMLHttpRequest必須設置的標志，以便使用Cookie進行調用，即withCredentials布爾值。默認情況下，調用不使用Cookies。由于這是一個簡單的GET請求，這不是預檢，但瀏覽器將拒絕不具有任何的響應Access-Control-Allow-Credentials: true報頭，并沒有提供給調用web內容的響應。
以下是客戶端和服務器之間的示例交換：
GET /resources/access-control-with-credentials/ HTTP/1.1Host: bar.other User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: keep-alive Referer: http://foo.example/examples/credential.html Origin: http://foo.example Cookie: pageAccess=2 HTTP/1.1 200 OK Date: Mon, 01 Dec 2008 01:34:52 GMT Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2 X-Powered-By: PHP/5.2.6 Access-Control-Allow-Origin: http://foo.example Access-Control-Allow-Credentials: true Cache-Control: no-cache Pragma: no-cache Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT Vary: Accept-Encoding, Origin Content-Encoding: gzip Content-Length: 106 Keep-Alive: timeout=2, max=100 Connection: Keep-Alive Content-Type: text/plain [text/plain payload]
雖然第11行包含http://bar.other指向內容的Cookie ，但如果bar.other沒有響應Access-Control-Allow-Credentials: true（第19行），則響應將被忽略并且不會提供給Web內容。
認證請求和通配符
在響應有證書請求時，服務器必須在Access-Control-Allow-Origin標題的值中指定一個源，而不是指定“ *”通配符。
由于上述示例中的請求標頭包含Cookie標頭，因此如果Access-Control-Allow-Origin標頭的值為“*” ，則請求將失敗。但它不會失?。阂驗?code>Access-Control-Allow-Origin頭部的值是“ http://foo.example”（實際起源）而不是“ *”通配符，所以證書認知內容將返回到調用的Web內容。
請注意，上述Set-Cookie示例中的響應標頭還設置了另一個cookie。如果發(fā)生故障，則會引發(fā)異常（取決于所使用的API）。
HTTP響應標頭
本部分列出服務器為“跨源資源共享”規(guī)范定義的訪問控制請求發(fā)送的HTTP響應頭。上一節(jié)將概述這些實際情況。
訪問控制允許來源
返回的資源可能有一個Access-Control-Allow-Origin標題，其語法如下：
Access-Control-Allow-Origin: <origin> | *
該origin參數指定可以訪問資源的URI。瀏覽器必須執(zhí)行此操作。對于沒有憑據的請求，服務器可以指定“*”作為通配符，從而允許任何來源訪問資源。
例如，要允許http://mozilla.org訪問資源，您可以指定：
Access-Control-Allow-Origin: http://mozilla.org
如果服務器指定的是原始主機而不是“*”，那么它也可以在Vary響應頭中包含Origin來向客戶機指出服務器響應將根據Origin請求頭的值而不同。
訪問控制展示報頭
該Access-Control-Expose-Headers標題即可讓所有瀏覽器都允許訪問的服務器白名單頭。例如：
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
這允許X-My-Custom-Header和X-Another-Custom-Header標題暴露給瀏覽器。
訪問控制 - 最大 - 年齡
Access-Control-Max-Age報頭指示預檢請求的結果多久可以被緩存。有關預檢請求的示例，請參閱上述示例。
Access-Control-Max-Age: <delta-seconds>
該delta-seconds參數表示可以緩存結果的秒數。
訪問控制允許的憑據
Access-Control-Allow-Credentials報頭指示是否對所述請求的響應可以在被暴露credentials標記為真。當作為對預檢請求的響應的一部分使用時，這指示是否可以使用憑證進行實際請求。請注意，簡單的GET請求不是預檢的，所以如果請求使用憑證的資源，如果此資源不與資源一起返回，瀏覽器將忽略該響應，并且不會返回到Web內容。
Access-Control-Allow-Credentials: true
以上討論了認證請求。
訪問控制允許的方法
該Access-Control-Allow-Methods頭指定訪問資源時所允許的一種或多種方法。這用于響應預檢請求。上面討論了預先請求的條件。
Access-Control-Allow-Methods: <method>[, <method>]*
上面給出了一個預檢請求的示例，其中包括將此標頭發(fā)送給瀏覽器的示例。
訪問控制允許報頭
所述Access-Control-Allow-Headers報頭在響應用來預檢請求，以指示在進行實際請求時HTTP標頭都可以使用。
Access-Control-Allow-Headers: <field-name>[, <field-name>]*
HTTP請求標頭
本節(jié)列出客戶端在發(fā)出HTTP請求時可能使用的標題，以便利用跨源共享功能。請注意，在調用服務器時會為您設置這些標頭。使用跨站點XMLHttpRequest功能的開發(fā)人員不必以編程方式設置任何跨源共享請求標頭。
起源
Origin報頭指示跨站點接入請求或預檢請求的來源。
Origin: <origin>
起源是一個URI，表示請求發(fā)起的服務器。它不包含任何路徑信息，但僅包含服務器名稱。
注：在origin可以為空字符串; 例如，如果源是dataURL ，這很有用。
請注意，在任何訪問控制請求中，始終發(fā)送Origin標題。
訪問控制請求法
該Access-Control-Request-Method發(fā)出的預檢要求，讓服務器知道實際的請求時會怎樣使用HTTP方法時使用。
Access-Control-Request-Method: <method>
這種用法的例子可以在上面找到。
訪問控制請求報頭
該Access-Control-Request-Headers發(fā)出的預檢要求，讓服務器知道什么實際的請求時HTTP標頭的時候會用到頭使用。
Access-Control-Request-Headers: <field-name>[, <field-name>]*
這種用法的例子可以在上面找到。
產品規(guī)格
規(guī)范 | 狀態(tài) | 評論 |
|---|---|---|
在該規(guī)范中獲取'CORS'的定義。 | 生活水平 | 新定義; 取代W3C CORS規(guī)范。 |
瀏覽器兼容性
特征 | Chrome | Edge | 火狐 | Internet Explorer | Opera | 蘋果瀏覽器 |
|---|---|---|---|---|---|---|
基本支持 | 4 | 12 | 3.5 | 10 | 12 | 4 |
特征 | Android的 | 適用于Android的Chrome | Edge 移動 | 適用于Android的Firefox | IE手機 | Opera Android | iOS Safari |
|---|---|---|---|---|---|---|---|
基本支持 | 2.1 | （是） | （是） | 1.0 | （是） | 12 | 3.2 |
兼容性說明
Internet Explorer 8和9通過該
XDomainRequest對象公開CORS ，但在IE 10中完全實現。盡管Firefox 3.5引入了對跨站點XMLHttpRequests和Web字體的支持，但某些請求在新版本之前是有限的。具體來說，Firefox 7引入了WebGL紋理的跨站點HTTP請求功能，并且Firefox 9添加了對使用的畫布上繪制的圖像的支持
drawImage。
擴展內容
代碼示例顯示
XMLHttpRequest和跨源資源共享跨服務器端透視資源共享（PHP等）
跨源資源共享規(guī)范
XMLHttpRequest取API
與所有（現代）瀏覽器一起使用CORS
使用CORS - HTML5巖石
堆棧溢出回答與“如何”信息處理常見問題：
如何避免CORS預檢
如何使用CORS代理來解決“無訪問控制 - 允許源標頭”
如何解決“Access-Control-Allow-Origin頭部不能是通配符”