共计 4019 个字符，预计需要花费 11 分钟才能阅读完成。
同源策略
同源策略是一个重要的安全策略，它用于限度一个 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.document
window.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=foo
WebSocket：该协定不履行同源政策，只有服务器反对，就能够通过它进行跨源通信。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 等根底常识
