何时安全启用CORS？
我正在开发一个JSON / REST Web API，我特别希望第三方网站能够通过AJAX调用我的服务。 因此，我的服务正在发送着名的CORS标题：
Access-Control-Allow-Origin: * 它允许第三方网站通过AJAX调用我的服务。 迄今为止都很好。
然而，我的networkingapi的一个小部分是非公开的，需要authentication（OAuth和access_token cookie相当标准的东西）。 在我的网站的这一部分启用CORS是否安全？
一方面，如果第三方网站可能有一个也与我的服务的这部分交互的ajax客户，那将是很酷的。 然而，起源相同的原因首先在于这可能是有风险的。 您不希望任何后来访问的网站能够访问您的私人内容。
我担心的情况是，用户通过网站或通过他信任的网站login我的networkingAPI，他忘记注销。 这是否允许每个其他网站，他后来访问他的私人内容使用现有的会议？
所以我的问题：
- 在非公开内容上启用CORS是否安全？
- 如果启用了CORS的服务器通过cookie设置session_token，这个cookie是否会保存在CORS服务器或主网页服务器的域下？
在回答第二个问题时（如果启用了CORS的服务器通过Cookie设置session_token？），则Cookie将保存在CORS服务器的域下。 主网页的JS代码无法访问cookie，即使通过document.cookie 。 只有在设置.withCredentials属性时才.withCredentials cookie发送到服务器，即使如此，只有在服务器设置Access-Control-Allow-Credentials标头时才会接受。
你的第一个问题是更开放的一点。 这是相当安全的，但有办法绕过东西。 例如，攻击者可以使用DNS中毒技术来使预检请求击中实际的服务器，但是将实际的CORS请求发送给stream氓服务器。 以下是关于CORS安全性的更多资源：
- http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
- owasp.org CORS CheatSheet
最后，您的担心是让任何网站访问您的CORS数据。 为了防止这种情况发生，您不应使用Access-Control-Allow-Origin: *标题。 相反，你应该回显用户的Origin值。 例如：
Access-Control-Allow-Origin: http://www.example.com
此标题将只允许http://www.example.com访问响应数据。
CORS的目的是允许XHR请求的跨域请求，同时赋予服务器权限，指定哪些源可以访问哪个资源。 特别是，CORS引入了Origin头域，它允许服务器分开定期和可能的XHR请求。 这个标题字段不能由用户设置或改变，而是由浏览器为XHR请求设置。
所以如果你有一个只被XHR使用的API，你可以（也应该）要求这个请求符合CORS。 特别是如果请求也可以修改你的服务器上的状态，否则你会很容易CSRF。
注意CSRF攻击是可能的，不pipeCORS使用其他方法伪造GET和POST请求。 如果服务器允许，CORS只能访问服务器对JavaScript的XHR请求的响应。
