同源策略

同源策略是一个重要的安全策略，它用于限度一个origin的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮忙阻隔歹意文档，缩小可能被攻打的媒介。提交表单不受同源政策的限度。因为不须要响应。

协定雷同  域名雷同  端口雷同

限度范畴：
（1） Cookie、LocalStorage 和 IndexDB 无奈读取。
（2） DOM 无奈取得。
（3） AJAX 申请不能发送（是否携带cookie）。

躲避

一、共享cookie

两个网页一级域名雷同，只是二级域名不同。

document.domain = 'example.com';document.cookie = "test1=hello";
Set-Cookie: key=value; domain=.example.com; path=/

二、iframe

DOM 获取

两个网页齐全不同源，无奈拿到dom。两个网页一级域名雷同，只是二级域名不同

document.domain = 'example.com';

父级子级获取

document.getElementById("myIFrame").contentWindow.documentwindow.parent.document.body
跨域窗口的通信

对于齐全不同源的网站，目前有三种办法，能够解决跨域窗口的通信：

片段辨认符（fragment identifier）window.name跨文档通信API（Cross-document messaging）window.postMessage

1. 片段辨认符（fragment identifier）

父窗口

var src = originURL + '#' + data;document.getElementById('myIFrame').src = src;

子窗口通过监听hashchange事件失去告诉

window.onhashchange = checkMessage;

子窗口能够扭转父窗口的片段标识符

parent.location.href= target + "#" + hash;

2. window.name
浏览器窗口有window.name属性。这个属性的最大特点是，无论是否同源，只有在同一个窗口里，前一个网页设置了这个属性，后一个网页能够读取它。

这种办法的长处是，window.name容量很大，能够搁置十分长的字符串；毛病是必须监听子窗口window.name属性的变动，影响网页性能。

3. postMessage

发送：

var popup = window.open('http://bbb.com', 'title');popup.postMessage('Hello World!', 'http://bbb.com');
window.opener.postMessage('Nice to see you', 'http://aaa.com');

通过message事件，监听对方的音讯：

window.addEventListener('message', function(e) {},false);

window.postMessage, 传递自定义message 或 LocalStorage 数据。

三、ajax

异步JavaScript和XML。疾速地将增量更新出现在用户界面上，而不须要重载（刷新）整个页面。

JSONP ： http://example.com/ip?callback=fooWebSocket ： 该协定不履行同源政策，只有服务器反对，就能够通过它进行跨源通信。CORS ： 跨域资源共享
CORS

CORS须要浏览器和服务器同时反对。目前，支流的浏览器都反对cors。

整个CORS通信过程，都是浏览器主动实现，不须要用户参加。对于开发者来说，CORS通信与同源的AJAX通信没有差异，代码齐全一样。浏览器一旦发现AJAX申请跨源，就会主动增加一些附加的头信息，有时还会多出一次附加的申请，但用户不会有感觉。因而，实现CORS通信的要害是服务器。 只有服务器实现了CORS接口，就能够跨源通信。

简略申请（simple request）和非简略申请（not-so-simple request）

简略申请

（1) 申请办法是以下三种办法之一：HEAD｜GET｜POST
（2）HTTP的头信息不超出以下几种字段：Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type，Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

根本流程

对于简略申请，浏览器间接收回CORS申请。具体来说，就是在头信息之中，减少一个Origin字段。如果Origin指定的域名

- 不在许可范畴内，服务器会返回一个失常的HTTP回应。

浏览器收到这个回应发现这个回应的头信息没有蕴含Access-Control-Allow-Origin字段，就晓得错了，从而会抛出一个谬误，被XMLHttpRequest的onerror回调函数捕捉。此时HTTP回应的状态码可能是200。

- 在许可范畴内，服务器返回的响应会多出几个头信息字段。

Access-Control-Allow-Origin：该字段是必须的，其值可能是申请时Origin字段的值，也可能是一个*，示意承受任意域名申请。
Access-Control-Allow-Credentials：该字段可选，其值类型是布尔型，示意是否容许发送Cookie。默认状况下Cookie不包含在CORS申请中。
Access-Control-Expose-Headers ：该字段可选。CORS申请时，XMLHttpRequest对象的getResponseHeader()办法只能拿到6个根本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其余字段，就必须在Access-Control-Expose-Headers外面指定。

withCredentials 属性，携带cookie

默认状况下，CORS申请默认不发送Cookie和Http认证信息，如果要把Cookie发送到服务器，首先要指定Access-Control-Allow-Credentials字段。

Access-Control-Allow-Credentials = true

另一方面，须要在AJAX申请中关上withCredentials属性。 申请携带cookie

xhr.withCredentials = true;

如果设置该属性为false，即便服务器批准发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会解决。如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，能够显式敞开withCredentials。

须要留神的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与申请网页统一的域名。

同时，Cookie仍然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其余域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无奈读取服务器域名下的Cookie。

非简略申请

非简略申请是那种对服务器有特殊要求的申请，比方申请办法是PUT或DELETE，或者Content-Type字段的类型是application/json。

非简略申请的CORS申请，会在正式通信之前，减少一次HTTP查问申请，称为"预检"申请（preflight）。浏览器先询问服务器，以后网页所在的域名是否在服务器的许可名单之中，以及能够应用哪些HTTP动词和头信息字段。

"预检"申请用的申请办法是OPTIONS，通过后浏览器才会收回正式的XMLHttpRequest申请，否则就报错。更多具体见浏览器同源政策及其躲避办法。

一旦服务器通过了"预检"申请，当前每次浏览器失常的CORS申请，就都跟简略申请一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。

预检响应头

Access-Control-Allow-Credentials：每次回应都必然蕴含的。
Access-Control-Allow-Methods ： 首部字段用于预检申请的响应。其指明了理论申请所容许应用的 HTTP 办法。
Access-Control-Allow-Headers ：如果浏览器申请包含Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必须的。用于预检申请的响应，它也是一个逗号分隔的字符串，其指明了理论申请中容许携带的首部字段，不限于浏览器在"预检"中申请的字段。
Access-Control-Max-Age：该字段可选，用来指定本次预检申请的有效期，单位为秒。下面后果中，有效期是20天（1728000秒），即容许缓存该条回应1728000秒（即20天），在此期间，不必收回另一条预检申请。
Access-Control-Allow-Credentials：同简略申请。

与JSONP的比拟

CORS与JSONP的应用目标雷同，然而比JSONP更弱小。
JSONP只反对GET申请，CORS反对所有类型的HTTP申请。JSONP的劣势在于反对老式浏览器，以及能够向不反对CORS的网站申请数据。

参考：
按本人的了解，整顿自阮一峰老师【浏览器同源政策及其躲避办法】
MDN【浏览器的同源策略】
Access-Control-Allow-Headers等根底常识