我已经使用CORS很长时间了，可以从其他域读取ajax响应。
我和一位同事讨论过关于CORS的问题 - 在讨论时 - 他提供了一个我认为与CORS问题无关的例子。
他说：相同的原始政策是，如果您已登录到您的银行并且 访问我的网站，我无法利用您的凭据并进行交叉 原始请求到您的银行并发给自己钱。
但在我看来，这是一种纯粹的csrf攻击，与CORS无关（除非阅读ajax的回复）：
所以我说：
关于您撰写的内容：＆＃34;如果您已登录银行并继续 我的网站，我无法利用您的凭据并成为交叉起源 要求你的银行给自己发钱。＆＃34; ........如果我去你的 网站，你向银行运行ajax请求：银行服务器将看到 请求。如果你用withCredentials运行ajax请求，那么 cookies将被发送我认为您正在谈论阻止CSRF攻击
然后他说：
不，CSRF有所不同。 CSRF就是我偷偷摸摸一张图片的时候 按钮在您的网站上发出请求以绕过相同的来源 政策。
（恕我直言 - 不！ - 你不必偷偷把任何东西都带到我的网站上。企业社会责任基金是你代表我做出不必要的请求来做恶事 - 你不必偷偷摸摸的东西）
所以我告诉他：
他说：例如，您可以将html表单发送到已知位置 - 银行所以解决方案是cookie /隐藏字段匹配服务器值所以如果恶意网站正在做一个请求 - 它不会有 隐藏字段值您的示例 - 谈论csrf攻击。那个部分 在那里你无法阅读回应 - 是唯一的角色部分。 我只是说银行的例子在这里有点无关（对CORS的讨论）
当然是相关的
最后我说：
IMO - CORS是为（示例）而设计的：
让a.com向Facebook运行ajax请求以获取所有朋友 - 其中 更有意义的地方
问题：
学习，变得更好，为了解决这种困惑，感到平静 - 我是对的吗？
答案 0 :(得分：1)
简短的回答是，为了使他的攻击成为可能，假设任何突变都是使用POST / PUT / DEL发出的，你的银行必须启用CORS才能允许XHR（飞行前检查）否则会失败）并且容易受到CSRF攻击。
当然，如果银行容易受到CSRF的影响，那么一个简单的表格也可以解决问题。
所以你是对的。 CORS不会阻止CSRF，它所做的只是放宽同源策略强制执行的限制。