理解CORS上的XMLHttpRequest（responseText）
对于一个项目，我正在寻找各种各样的HTML5和Javascript元素以及围绕它们的安全性，而我正试图让我的头脑刚好在CORS的周围。
根据我的testing，如果我删除..
<?php header("Access-Control-Allow-Origin: *"); header('Access-Control-Allow-Methods: GET, POST, OPTIONS'); ?> ..从试图访问的页面我看到在控制台login在Chrome中的以下内容：
XMLHttpRequest cannot load http://www.bla.com/index.php. Origin http://bla2.com is not allowed by Access-Control-Allow-Origin.
我明白这是正确的，但是Wireshark在返回时显示HTTP / 1.1 200 OK，并且在数据中显示被请求的页面的来源。 那么是不是浏览器和JavaScript阻止了responseText被实际使用，即使它实际上被转移了？
代码如下：
function makeXMLRequest() { xmlhttp=new XMLHttpRequest(); xmlhttp.onreadystatechange = function() { if (xmlhttp.readyState==4) { alert(xmlhttp.responseText); } } xmlhttp.open("GET","http://www.bla.com/index.php",true); xmlhttp.send(); }
提前致谢。
对于像GET或POST这样的“简单的”HTTP动词，是的，整个页面被抓取，然后浏览器决定JavaScript是否使用内容。 服务器不需要知道请求来自哪里; 浏览器的工作是检查服务器的回复，并确定JS是否被允许查看内容。
对于像PUT或DELETE这样的“非简单”HTTP动词，浏览器使用OPTIONS请求发出“预检请求”。 在这种情况下，浏览器首先分别检查Access-Control-Allow-Origin和Access-Control-Allow-Methods ，检查是否支持域和动词。 （有关详细信息，请参阅HTML5 Rock的CORS页面上的“ 处理非简单请求 ”）。预检响应还列出了Access-Control-Allow-Headers包含的允许的非简单标Access-Control-Allow-Headers 。
这是因为允许客户端向服务器发送DELETE请求可能是非常糟糕的，即使JavaScript永远不会看到跨域结果 – 再次记住，服务器通常没有任何义务来validation请求来自一个合法的域名（尽pipe它可以使用来自请求的Origin头部）。
那么是不是浏览器和JavaScript阻止了responseText被实际使用，即使它实际上被转移了？
是。 你可以用JS来做任何你喜欢的请求。
它是访问相同的来源策略阻止的数据。
请求做恶意事件（例如“ POST http://bank.example/give/money?to=attacker ”或“ POST http://forum.example.com/post?message=spamspamspamspam" ）被称为CSRF攻击并且必须由服务器来防御。
