我试图理解为什么 CORS 以它的工作方式工作。
当我从了解到这个职位，当从网页www.a.com使得AJAX请求www.b.com，那么它的www.b.com是决定是否请求应该被允许。
但是在这样的模型中，客户端究竟保护了什么？例如，如果黑客成功地将 XSS 脚本注入到我的页面，那么它会向他的域发出 AJAX 请求以存储用户数据。所以黑客的域肯定会允许这样的请求。
我认为www.a.com应该决定允许请求的域。因此，理论上在标题Access-Control-Allow-Origin 中，我想放置允许 AJAX CORS 请求的域的整个列表。
有人可以解释当前的 CORS 实现处理哪些安全问题吗？
正如我从这篇文章中了解到的，当页面 from 向
www.a.com发出 AJAX 请求时www.b.com，www.b.com决定是否应该允许请求。
不完全的。请求不会被阻止（至少，如果它很简单）。
默认情况下，运行的 JavaScriptwww.a.com被禁止访问来自www.b.com.
CORS 允许www.b.com授予 JavaScriptwww.a.com访问响应的权限。
但是在这样的模型中，客户端究竟保护了什么？
它阻止作者使用访问过两个站点并已通过身份验证（因此可以访问非公开数据）的用户的浏览器www.a.com读取数据。www.b.comwww.b.com
例如，Alice 登录了 Google。Alice 访问malicious.example它使用 XMLHttpRequest 从 访问数据gmail.com。爱丽丝有一个 GMail 帐户，因此回复在她的收件箱中包含最近的电子邮件列表。同源策略阻止malicious.example读取它。
例如，黑客成功将 XSS 脚本注入我的页面，然后向他的域发出 AJAX 请求以存储用户数据。所以黑客域肯定会允许这样的请求。
正确的。XSS 是一个不同的安全问题，需要在源头（即在www.a.com浏览器中而不是在浏览器中）解决。
除了@Quentin 的出色回答之外，还有另一种称为内容安全策略的技术，它描述了您所追求的内容。
我认为 www.a.com 应该决定允许请求的域。因此，理论上在标题 Access-Control-Allow-Origin 中，我想放置允许 AJAX CORS 请求的域的整个列表。
使用 CSP，您可以设置域中的标头（www.a.com在您的示例中）以限制 AJAX 请求：
connect-src 限制您可以连接的来源（通过 XHR、WebSockets 和 EventSource）。
因此，要使用它，您可以将此Content-Security-PolicyHTTP 标头添加到您的 HTML 响应中：
Content-Security-Policy: connect-src 'self'
这会将 AJAX 请求限制www.a.com为该标头是否在来自www.a.com以下内容的响应中：
'self' 匹配当前来源，但不匹配其子域