CORS也已经成为主流的跨域解决方案，不过CORF也会引发CSRF，本文先分享第三方的一个前端工具箱全面展示那些浏览器版本支持CORS，由于各家浏览器厂商因为各自原因在不同的版本里支持的标准不同，这个工具小而美，可以清晰的比较不同版本浏览器前端技术兼容性对照表。
先看图下面这个网站可以很方便的查看不同版本浏览器对CORS的支持力度，IE10，IE11，Chrome，Firefox，Safari太多了一个都少不了，基本涵盖常见或者不常见的浏览器了，话说做前端真不容易啊。
https://caniuse.com/#search=cors
如图所示，这个图表不是单纯的显示支持与不支持，还做了一些细分：
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 跨域 实现思路及相关解决方案 写的很好
其他例如CSS Grid Layout (level 1)
CSS Flexible Box Layout Module
ECMAScript 2015 (ES6)
也可以按不同的浏览器版本直接对比对不同技术规范的支持，比如H5选择最新版本的IE11，Chrome，Firefox，Safari比较：
分至少部分支持和混合支持：
如果你遇到跨域问题还没有使用CORS那么赶紧往下看。
同源政策
维基百科上关于同源策略的定义http://en.wikipedia.org/wiki/Same_origin_policy
同源策略是Web应用程序安全模型中的一个重要概念。根据该策略，Web浏览器允许第一个Web页面中包含的脚本访问第二个Web页面中的数据，但前提是两个Web页面具有相同的源。原点定义为URI方案，主机名和端口号的组合。此策略可防止一个页面上的恶意脚本通过该页面的文档对象模型访问另一个网页上的敏感数据。
放宽同源政策（跨域解决方案）
在某些情况下，同源策略限制性太强，对使用多个子域的大型网站造成问题。首先，使用诸如使用片段标识符或window.name属性的许多变通方法来在驻留在不同域中的文档之间传递数据。现代浏览器支持多种技术，以受控方式放宽同源策略：
1.document.domain属性
如果两个窗口（或框架）包含将域设置为相同值的脚本，则这两个窗口将放宽同源策略，并且每个窗口可以与另一个窗口交互。例如，从orders.example.com和catalog.example.com加载的文档中的协作脚本可能会将其document.domain属性设置为“example.com”，从而使文档看起来具有相同的来源并使每个文档都能够读取另一个的属性。设置此属性会隐式将端口设置为null，大多数浏览器将从端口80或甚至未指定的端口进行不同的解释。要确保浏览器允许访问，请设置两个页面的document.domain属性。
2.跨源资源共享(CORS)
另一种放宽同源策略的技术是以跨源资源共享的名义标准化的。此标准使用新的Origin请求标头和新的Access-Control-Allow-Origin响应标头扩展HTTP。它允许服务器使用标头明确列出可能请求文件或使用通配符的起源，并允许任何站点请求文件。诸如Firefox 3.5，Safari 4和Internet Explorer 10之类的浏览器使用此标头来允许具有XMLHttpRequest的跨源HTTP请求，否则这些请求将被同源策略禁止。
3.跨文档消息
另一种技术是跨文档消息传递，允许来自一个页面的脚本将文本消息传递到另一页面上的脚本，而不管脚本来源如何。在Window对象上异步调用postMessage()方法会在该窗口中触发“onmessage”事件，从而触发任何用户定义的事件处理程序。一个页面中的脚本仍然无法直接访问另一个页面中的方法或变量，但它们可以通过此消息传递技术安全地进行通信。
4.JSONP
由于允许HTML<script>元素从其他域检索和执行内容，因此页面可以绕过同源策略，并通过加载返回JSONP有效负载的资源从不同的域接收JSON数据。JSONP有效负载由预定义函数调用包装的内部JSON有效负载组成。当浏览器加载脚本资源时，将调用指定的回调函数来处理包装的JSON有效负载。
5.WebSockets
现代浏览器将允许脚本连接到WebSocket地址而不应用同源策略。但是，它们会在使用WebSocketURI时识别，并将Origin：标头插入到请求中，该请求指示请求连接的脚本的来源。为确保跨站点安全性，WebSocket服务器必须将标头数据与允许接收回复的原始白名单进行比较。
为什么CORS很重要？
JavaScript和网络编程多年来实现了跨越式发展，但同源政策仍然存在。这可以防止JavaScript跨域边界发出请求，并产生了各种用于发出跨域请求的黑客攻击。
CORS引入了一种标准机制，可供所有浏览器用于实现跨域请求。规范定义了一组标头，允许浏览器和服务器就允许（和不允许）哪些请求进行通信。CORS通过为所有人提供API访问来延续开放网络的精神。
CORS与JSONP的使用目的相同，但是比JSONP更强大。
CORS与JSONP的比较可以看看https://stackoverflow.com/questions/12296910/so-jsonp-or-cors
为什么JSONP仍然是强制性的
为什么JSONP仍然是强制性的
解决方案
使用JSONP是确保与旧浏览器的良好兼容性并处理错误配置的防火墙/代理问题的唯一解决方案。但是，CORS提供了正确错误处理的优势，因此我们不希望将自己局限于JSONP。
在我们的JavaScript客户端的最新版本中，我们决定使用CORS来回退JSONP。在客户端初始化时，我们检查浏览器是否支持CORS，然后执行OPTIONS查询以检查是否没有阻止CORS请求的防火墙/代理。如果有任何错误，我们会回避JSONP。我们的JavaScript客户端可以使用所有这些逻辑，而无需为客户更改任何API /代码。
拥有CORS支持以及JSONP上的自动回退是我们发现的最佳方式，可确保提供卓越的服务质量并支持所有角落情况。如果您看到其他任何方式，我们非常欢迎您的反馈。
小结：JSONP只支持GET请求，CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。
如何使CORS生效
为了使CORS正常生效，我们可以添加HTTP标头，允许服务器描述允许使用Web浏览器读取该信息的一组源，并且对于不同类型的请求，我们必须添加不同的标头。该请求可以主要分为简单请求和预检请求。
简单请求
请求不会触发CORS预检是所谓的简单请求。一个简单的请求应满足以下所有条件：
对于一个简单的请求，要使CORS正常工作，Web服务器应该设置一个HTTP头：
Access-Control-Allow-Origin: *设置此标头意味着任何域都可以访问该资源。如果我们想限制到一个特定域，我们可以将其设置为：
Access-Control-Allow-Origin: http://specific.domain.example预检请求
预先请求的请求首先通过该OPTIONS方法向服务器发送HTTP请求，以确定实际请求（以下请求）是否可安全发送。预检请求应满足以下所有条件：
对于预先发出的请求，要使CORS正常工作，Web服务器应设置一些HTTP标头：
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攻击
根据同源策略，既然允许跨源写入，这就可能会导致安全问题引发CSRF攻击 。
要防止CSRF攻击，请在请求中检查不可语量的令牌。例如，在HTTP参数中有一个随机生成的令牌，表示名称_csrf。
CSRF解决方案参考：https://github.com/OWASP/CheatSheetSeries
需要保护的资源不受CSRF漏洞的影响
以下列表假定您没有违反RFC2616第9.1.1节，通过使用GET请求进行状态更改操作。
注意：如果你违反任何理由，你也需要保护这些资源，其中大部分是使用默认实现form tag [GET method]，href和src属性。
- 使用POST表单标签
- Ajax / XHR调用
CSRF防御建议摘要
我们建议基于令牌的CSRF防御（有状态/无状态）作为缓解应用程序中CSRF的主要防御。仅对于高度敏感的操作，我们还建议基于用户交互的保护（重新认证/一次性令牌，详见6.5节）以及基于令牌的缓解。
作为一项纵深防御措施，请考虑从“深度缓解防御”部分实施一项缓解措施（您可以根据其中提到的问题选择适合您的生态系统的缓解措施）。建议不要使用这些纵深防御缓解技术（不使用基于令牌的缓解）来减轻应用程序中的CSRF。
初级防御技术
基于令牌的缓解
这种防御是减轻CSRF的最受欢迎和推荐的方法之一。它可以通过状态（同步器令牌模式）或无状态（基于加密/散列的令牌模式）来实现。请参阅第4.3节，了解如何减轻应用程序中的登录CSRF。对于所有缓解措施，隐含的是应遵守一般安全原则
- 应遵循强加密/ HMAC功能。
注意：您可以根据组织需求选择任何算法。我们建议使用AES256-GCM进行加密，使用SHA256 / 512进行HMAC。
- 应保持严格的密钥轮换和令牌生存期策略。可以根据您的组织需求设置策略。可以在此处找到OWASP的通用密钥管理指南。
参考：
