此问题仅涉及防止跨站点请求伪造攻击
它特别是关于：通过源报头（CORS）的保护是否与通过CSRF令牌的保护一样好
例如：
- Alice使用浏览器登录（使用cookie）以“https://example.com”. 我猜她使用的是现代浏览器
- 爱丽丝访问“https://evil.com，并且evil.com的客户端代码对https://example.com“（典型的CSRF场景）
因此：
- 如果我们不检查源报头（服务器端），并且没有CSRF令牌，我们就有一个CSRF安全漏洞
- 如果我们检查CSRF令牌，我们是安全的（但这有点乏味）
- 如果我们确实检查了源代码头，那么来自evil.com客户端代码的请求应该被阻止，就像使用CSRF令牌时一样——除非evil.com的代码能够以某种方式设置源代码头
我知道，如果我们相信W3C规范在所有现代浏览器中都能正确实现，那么XHR就不可能实现这一点（例如，请参阅跨源资源共享的安全性），至少不可能
但是其他类型的请求呢？例如表单提交？正在加载脚本/img/。。。标签或者页面可以使用任何其他方式（合法）创建请求？或者是一些已知的JS黑客
注：我不是说
- 本地应用程序
- 操纵浏览器
- example.com页面中的跨站点脚本错误
要知道，如果我们相信W3C规范在所有现代浏览器中都能正确实现，那么XHR就不可能实现这一点（例如，请参阅跨源资源共享的安全性），至少不可能
在一天结束时，你必须；“信托”；客户端浏览器用于安全存储用户数据并保护会话的客户端。如果您不信任客户端浏览器，那么除了静态内容之外，您应该停止使用web。即使使用CSRF令牌，您也相信客户端浏览器会正确遵守同源策略
虽然以前存在浏览器漏洞，如IE 5.5/6.0中的漏洞，攻击者有可能绕过同源策略并执行攻击，但通常情况下，一旦发现这些漏洞并自动更新大多数浏览器，这些风险将得到最大程度的缓解
但是其他类型的请求呢？例如表单提交？正在加载脚本/img/。。。标签或者页面可以使用任何其他方式（合法）创建请求？或者是一些已知的JS黑客
Origin头通常仅针对XHR跨域请求发送。图像请求不包含标题
注：我不是说
本地应用程序
操纵浏览器
example.com页面中的跨站点脚本错误
我不确定这是否属于受操纵的浏览器，但旧版本的Flash允许设置任意头，这将使攻击者能够从受害者的机器发送带有伪造的referer头的请求，以便执行攻击