CORS 简介
由于SOP限制了很多跨域的业务场景，于是寻求某种技术来实现跨域的资源访问。而JSONP就是其中的代表，可JSONP只是程序员想到的一种编码技术，并非在协议层面解决跨域问题，从而容易出现种种问题。为了更安全的跨域资源访问，于是有了CORS (Cross-Origin Resource Sharing 跨域资源共享)诞生。
如何提供安全的跨域资源访问是CORS要解决的问题。CORS使用检查请求头部的相关字段和服务端配置的规则进行对比，来选择是否允许跨域。(个人理解就像协议一般规定好了一定规则，满足了才可以跨域，否则不允许跨域)。但凡是要配置规则的程序，难免会出现一些意外，就像很多程序员写不出恰当的正则一样。CORS也不例外，当服务端配置的规则不够合理，导致非同域的资源可以互相访问，CORS 反而使SOP的保护机制土崩瓦解。
因此，CORS漏洞成因很明显，服务端配置的规则不当所导致的。
CORS如何实现跨域
服务端会配置了Access-Control-Allow-Origin头，当浏览器发送数据包时，浏览器会自动加上Origin字段并且和服务端进行比对，如果为预期，那么允许接收，否则浏览器会因为同源策略而不接收。
服务端配置代码如下所示：
header("Access-Control-Allow-Origin:http://www.baidu.com");
header("Access-Control-Allow-Credentials:true");
当浏览器发送的请求包中Origin头部为www.baidu.com时，则会允许读取该域的资源并且第二行表示可以带上cookie去访问，否则则拒绝。当然可以更加灵活的配置，比如举个例子如下，
header("Access-Control-Allow-Origin:*");
header("Access-Control-Allow-Credentials:true");
众所周知，*是通配符的意思，那么这样就变成任意域名都可以读取这个域的资源并且还会带上cookie，显然不符合SOP的要求，所以浏览器是不允许这样的配置存在。这个例子比较极端，只是想表述，当配置不当则会导致恶意的域可以访问目标域的资源，从而导致信息泄露。
修复方式
既然是配置问题，那么就严格检查配置是否合理，配置合理的情况下，这个问题是避免的。
参考链接
由于比较懒，没有自己动手写个小示例，网上找了个链接我觉得讲解的很好，也有相应的示例。还有有些参考文章还涉及到了简单请求和复杂请求的知识，但个人觉得对理解CORS的问题，只需搞明白几个字段就大致OK了，至于再深入一下多学习一些也是没毛病的。
简单请求和非简单请求
CORS跨域学习，有实例
