什么是阻止恶意代码欺骗“Origin”头来利用CORS？
我的理解是，如果在foo.com的页面上运行的客户端脚本想要从bar.com请求数据，那么在请求中必须指定标头Origin: http://foo.com ，并且bar必须使用Access-Control-Allow-Origin: http://foo.com响应。
什么是阻止恶意代码从网站roh.com只是欺骗头Origin: http://foo.com要求从网页页面？
浏览器控制着Origin头的设置，用户不能覆盖这个值。 所以你不会看到来自浏览器的Origin头文件。 恶意用户可以制作一个手动设置Origin头部的curl请求，但是这个请求将来自浏览器之外，并且可能没有浏览器特定的信息（如cookie）。
记住：CORS不是安全的。 不要依靠CORS来保护您的网站。 如果您正在提供受保护的数据，请使用Cookie或OAuth令牌或Origin头以外的其他Origin来保护该数据。 CORS中的Access-Control-Allow-Origin标题只规定应该允许哪个起源发出跨域请求。 不要再依赖它了。
TLDR：没有什么能阻止恶意代码欺骗来源。 发生这种情况时，您的服务器将永远不会知道它，并会根据请求采取行动。 有时这些请求/回应是昂贵的。 所以不要使用CORS代替任何types的安全措施。
最近我一直在和CORS一起玩，我也问过自己同样的问题。 我发现，当浏览器看到一个CORS请求时，浏览器可能足够聪明，但是你的服务器可能不那么聪明。
我发现的第一件事是头名称Origin是一个http 禁止标题名称 ，据说不能被程序修改。 这意味着您可以使用Google Chrome的“修改标题”在大约8秒内对其进行修改 。
为了testing这个，我设置了两个客户端域和一个服务器域。 我在服务器域中包含一个CORS白名单，允许来自客户端1的CORS请求，但不允许来自客户端2.然后testing了两个客户端，并且实际上客户端1的CORS请求成功，而客户端2失败。
然后，我伪造客户端2的Origin标头以匹配客户端1。 服务器收到伪造的Origin头名称，然后成功通过白名单检查（如果你是一个半空的人，则失败）。 之后，服务器通过消耗所有devise资源（数据库调用，发送昂贵的电子邮件，发送更昂贵的短消息等），继续尽职尽责。 完成之后，服务器高兴地将假冒的Access-Control-Allow-Origin头名称发送回浏览器。
我读过的文档指出， Access-Control-Allow-Origin值必须与请求中发送的Origin值完全一致。 这让我相信自从他们匹配之后，没有什么能够阻止成功的请求，但是我在Chrome中收到以下消息：
XMLHttpRequest无法加载
http://server.dev/test。 “Access-Control-Allow-Origin”标题的值为http://client1.dev，不等于提供的原点。 原因http://client2.dev因此不被允许访问。
我读的文件似乎并不准确。 Chrome的networking标签清楚地显示请求标头和响应标头值为http://client1.dev ，但是在错误中您可以看到Chrome知道真正的原点是http://client2.dev并正确拒绝了响应。
