我试图理解为什么CORS正在以它的工作方式工作。
我从this post了解到，当 www.a.com 的页面向 www.b.com 发出AJAX请求时，那就是 www.b.com 决定是否允许请求。
但是在这种模式中客户端的确切安全性是什么？ 例如，如果黑客成功向我的页面注入XSS脚本，那么它会向其域发出一个AJAX请求来存储用户数据。因此，黑客的域名将允许这样的请求。
我认为 www.a.com 应决定允许请求的域名。所以理论上在标题 Access-Control-Allow-Origin 中，我想把整个AJAX CORS请求允许的域列表。
有人可以解释当前CORS实现处理的安全问题吗？
答案 0 :(得分：23)
正如我从这篇文章中了解到，当
www.a.com的页面向我发出AJAX请求www.b.com时，www.b.com决定是否允许请求。
不完全。请求未被阻止。
默认情况下，www.a.com上运行的JavaScript被禁止访问来自www.b.com的响应。
CORS允许www.b.com授予www.a.com JavaScript访问响应的权限。
但是在这种模式中客户端的确切安全性是什么？
它阻止www.a.com的作者使用访问过这两个网站且已在www.b.com上进行过身份验证的用户浏览器从www.b.com读取数据（因此可以访问数据）这不是公开的。）
例如，Alice已登录Google。 Alice访问malicious.example，它使用XMLHttpRequest访问来自gmail.com的数据。 Alice拥有GMail帐户，因此回复中包含收件箱中最新电子邮件的列表。相同的原始政策阻止malicious.example阅读它。
例如，黑客成功地将XSS脚本注入到我的页面，然后它向他的域发出AJAX请求以存储用户数据。所以黑客域名肯定会允许这样的请求。
正确。 XSS是一个不同的安全问题，需要在源头处解决（即www.a.com而不是浏览器）。
答案 1 :(得分：5)
除了@Quentin's excellent answer之外，还有另一项称为Content Security Policy的技术，它描述了您的目标。
我认为www.a.com应决定允许请求的域名。所以理论上在头文件Access-Control-Allow-Origin中我想把整个AJAX CORS请求允许的域列表。
使用CSP，您可以设置域中的标头（示例中为www.a.com）以限制AJAX请求：
connect-src限制您可以连接的源（通过XHR，WebSockets和EventSource）。
因此，要使用此功能，您可以将此Content-Security-Policy HTTP标头添加到HTML响应中：
Content-Security-Policy: connect-src 'self'
如果该标头位于www.a.com的响应中，这会将AJAX请求限制为www.a.com：
'self'匹配当前原点，但不匹配其子域
See here支持的浏览器。