我试图理解CORS。 按我的理解，它是在浏览器中实现，以避免任何Ajax请求不是一个用户打开其他域的安全机制（URL中指定）
现在，由于这种限制，许多CORS的实施是为了使网站做跨起源请求。 但按我的理解实现CORS以身试法“同源策略” SOP的安全目的
CORS只是提供了该请求的服务器要满足额外的控制。 也许这能避免垃圾邮件发送者。
从维基百科 ：
为了发起跨源请求，浏览器发送具有起源HTTP报头中的请求。 标题的价值在于服务的页面的站点。 例如，假设在一个页面http://www.example-social-network.com试图在online-personal-calendar.com访问用户的数据。 如果用户的浏览器实现了CORS，下面的请求头将被发送：
原产地： http://www.example-social-network.com
如果online-personal-calendar.com允许请求时，它发送其响应一个访问控制允许来源标头。 标头的值表示原始站点被允许的。 例如，上一请求的响应将包含以下：
访问控制允许来源： http://www.example-social-network.com
如果服务器不允许跨域请求，浏览器将提供一个错误页面example-social-network.com代替online-personal-calendar.com响应。
要允许访问的所有页面，服务器可以发送如下响应头：
访问控制允许来源：*
然而，这可能不适合在安全性是一个问题的情况。
我缺少的是在这里吗？ 什么是CORS的的打算，以确保服务器VS固定客户。
同源策略
它是什么？
该同源策略是浏览器中标准化的安全措施。 在“原产地”主要是指“域”。 它可以防止不同来源的相互交融，以防止诸如跨站请求伪造攻击。
如何CSRF攻击的工作？
浏览器允许网站存储在客户端计算机上的信息，在饼干的形式。 这些cookie重视他们的一些信息，如饼干，当它被创建的时候，就会到期，谁设置cookie的名称等。饼干看起来是这样的：
Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]
所以这是一个巧克力饼干，这应该是从访问http://bakery.com及其所有子域。
这个cookie可能包含一些敏感数据。 在这种情况下，该数据是... chocolate 。 高度敏感的，因为你可以看到。
所以浏览器中存储这个cookie。 而每当用户对在此cookie是访问的域名的请求，该cookie将被发送到服务器为该域。 逍遥服务器。
这是一件好事。 服务器超级酷的方式来存储和检索，并从客户端的信息。
但问题是，这允许http://malicious-site.com到这些Cookie发送到http://bakery.com ， 而用户不知道！ 例如，请考虑以下情形：
# malicious-site.com/attackpage
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://bakery.com/order/new?deliveryAddress="address of malicious user"');
xhr.send();
如果你访问恶意网站，上面的代码执行和同源策略是不存在，恶意用户将下订单代表你，在他的地方拿到订单...你可能不喜欢这个。
发生这种情况是因为你的浏览器发送你的巧克力饼干来http://bakery.com ，这让http://bakery.com认为你正在为新秩序的要求， 故意 。 但你不是。
这一点，在平淡的话，CSRF攻击。 伪造的请求跨站点制作。 “跨站请求伪造”。 而且它不会工作，由于同源策略。
如何相同的起源政策解决这个问题？
它停止从发出请求到其他域的malicious-site.com。 简单。
换句话说，浏览器将不会允许任何网站不得向其他任何网站的请求。 这将阻止通过这样的请求相互交融，如AJAX不同的来源。
然而 ，从其他主机，例如图片，脚本，样式，内部框架，表单提交等资源加载不受此限制。 我们需要另一个墙来保护我们的面包店从恶意网站，通过使用CSRF令牌 。
CSRF令牌
如前所述，恶意网站仍然可以做这样的事情，而不违反同源策略：
<img src='http://bakery.com/order/new?deliveryAddress="address of malicious user"'/>
而浏览器将尝试从URL加载图像，从而产生一个GET请求到该URL发送所有的饼干。 为了阻止这种情况发生，我们需要一些服务器端的保护。
基本上，我们重视适当的熵的随机，唯一令牌用户的会话，它存储在服务器上，并且也将其发送到与形式的客户端。 当提交表单时，客户端发送一个令牌随请求，如果该令牌有效与否服务器验证。
现在我们已经做到了这一点，并恶意网站再次发送请求时，它总是会失败，因为没有为恶意网站知道用户的会话令牌没有可行的办法。
HEARTS
当需要时，该策略可以规避，当需要跨站点请求。 这就是所谓的CORS。 跨源资源共享。
这是通过具有“域”告诉浏览器来冷却，并允许这样的请求。 这种“告诉”的东西可以通过传递一个标题来完成。 就像是：
Access-Control-Allow-Origin: //comma separated allowed origins list, or just *所以，如果http://bakery.com通过这个头到浏览器，并在页面创建请求http://bakery.com是目前在原点列表中，那么浏览器就会让请求去，与曲奇。
有根据该原点定义1的规则。 例如，对于同一个域不同的端口是不一样的起源。 因此，如果端口是不同的浏览器可能会拒绝这个请求。 与往常一样，我们亲爱的Internet Explorer是例外。 IE浏览器将所有的端口相同的方式。 这是不规范的 ， 没有其他的浏览器的行为这种方式。 不要依赖此 。
JSONP
JSON与填充只是一个规避同源策略的方法，当CORS是不是一种选择。 这是有风险的，一种不好的做法。 避免使用此。
这是什么技术包括正在为像下面的其他服务器的请求：
<script src="http://badbakery.com/jsonpurl?callback=cake"></script>
由于同源策略不会阻止此请求2，该请求的响应将被加载到页面中。
该网址将最有可能使用JSON内容作出回应。 但是，仅仅包括页面上的内容JSON是不是要去帮助。 这将导致错误着，当然。 所以http://badbakery.com接受一个回调参数，并修改JSON数据，将其发送包裹在无论是传递给回调的参数。
因此，而不是返回，
{ user: "vuln", acc: "B4D455" }
这是无效的JavaScript抛出一个错误，它会返回，
cake({user: "vuln", acc:"B4D455"});
这是有效的JavaScript，它会得到执行，并且有可能存储在某个地方根据cake的功能，使的JavaScript的网页上其余的可以使用的数据。
这主要是所用的API将数据发送到其他领域。 再次，这是一个不好的做法，是有风险的，且应严格避免。
为什么JSONP不好？
首先，它是非常有限的。 如果请求失败（AT-至少不是一个健全的方式）不能处理任何错误。 你不能重试请求等。
它也需要你有一个cake在全球范围内这是不是很不错的功能。 愿厨师救你，如果你需要执行不同的回调多个JSONP请求。 这是通过临时解决职能由不同的库，但仍然做的事情的hackish的hackish的方式。
最后，你在DOM插入随机的JavaScript代码。 如果你不是100％确保远程服务将返回安全的蛋糕，你不能靠这个。
参考
1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin
2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details
其他值得读
http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html
http://tools.ietf.org/html/rfc3986 （抱歉：P）
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF）
同源策略（SOP）是该政策落实的浏览器，以防止漏洞通过跨站脚本（XSS）。 这主要是为了保护服务器，因为有许多场合，当一台服务器可以处理身份验证，饼干，会议等。
跨源资源共享（CORS）是放松的SOP的几个技术之一。 因为SOP是“接通”默认，在服务器侧设置CORS将允许请求以经由即使该请求是从一个不同的域发送一个XMLHttpRequest被发送到服务器。 如果你的服务器是为了服务于从其他域的请求（例如，如果你提供的是API），这变得非常有用。
我希望这清除了SOP和CORS和各的目的之间的区别。
