一、网站一般在需要共享资源给其他网站时（跨域传递数据），才会设置access-control-allow-origin HTTP头。而跨域传递数据也可以使用jsonp方式
二、如果www.a.com域设置了access-control-allow-origin:* http头, 其他任何域包括www.b.com域的js就可以使用Ajax技术读取到www.a.com域的数据
三、根据w3c标准：http://www.w3.org/TR/cors/#resource-requests，如果www.b.com域下js要读取到www.a.com域下的需要登录才能访问的资源，需要www.a.com域同时设置了 Access-Control-Allow-Credentials: true头（即允许third-party cookie）
并且如果设置access-control-allow-origin为*星号（任何域），则Access-Control-Allow-Credentials头是不能设置为true的，如下图，参见http://www.w3.org/TR/cors/#resource-requests
所以理论上网站设置了Access-control-allow-origin: *，并没有实际危害，因为并不能跨域读取私密数据（登录后才可见数据）
四、然而否存在实际危害取决于浏览器是否遵循该标准（chrome、firefox等主流浏览器均遵循）
浏览器发出跨域请求时，若Ajax没有setRequestHeader，则会直接发出请求，根据响应头中的access-control-allow-origin是否设置允许当前域（设置*，即允许任何域），来决定是否将数据交给js处理（其实数据已经返回到浏览器，但页面js无法拿到）
另外若同时设置了星号和withCredentials，浏览器也会拒绝将数据返回到js。浏览器在这个层面上是安全的
但是浏览器插件却往往会忽略http header的设置，比如postman，不免有其他利用方式。
所以服务器应设置白名单。（使用jsonp跨域共享资源存在更多风险，有机会写写jsonp）
五、测试使用的代码如下http://localhost/test.htm，发送请求到http://127.0.0.1/对于浏览器来说就是在跨域，方便测试
ps: setRequestHeader需要在open之后调用。如果调用了setRequestHeader，浏览器会先发出OPTION请求到目标网站，确认是否设置Access-Control-Allow-Headers: content-type等
update：发现许多网站会根据请求头中的Origin值然后设置Access-control-allow-origin，且同时设置了Access-Control-Allow-Credentials为true，导致可以被黑客利用
Access-control-allow-origin:null 是可以携带cookie的
======================分割线=================
六、不携带cookie的利用姿势
以上说的Access-control-allow-origin: *情况，是不能跨域读取（需cookie认证的）隐私数据。
但也存在特定场景下不需要cookie也能攻击的：
》基于ip认证的资源跨域读取
》缓存投毒，增加Vary: Origin http头可以避免