我想了解CORS。据我了解，它使您能够限制哪些域可以访问服务器上的资源。然而，这似乎不是完整的故事。例如，我有一个未启用 CORS 的 Web 服务。我无法通过 jQuery 从我的 Web 应用程序中访问此 Web 服务（该应用程序在 localhost 上运行）。但是，我可以从 Postman 访问 Web 服务。所以，我有点困惑。是否有一些涉及 CORS 的额外客户端工作？
【问题讨论】：
标签： javascript cors
服务器负责报告允许的来源。 Web 浏览器负责强制要求仅从允许的域发送请求。
CORS 在请求中包含Origin header 时应用于请求。这包括从 JavaScript 和 POST 请求发出的请求。它没有应用所有资源。来源是发出请求的协议、主机和端口。 JavaScript 发出的请求使用加载 JavaScript 的源，而不是加载它的源。
当未启用 CORS 时，浏览器将依赖 same origin policy。同源策略仅适用于脚本。浏览器将只允许从与加载页面相同的来源加载脚本。当没有明确允许来源时，假定相同的来源策略。
浏览器以外的 HTTP 客户端不会使用同源策略或 CORS。这些其他 HTTP 客户端发出的请求没有来源。除非 Postman 桌面应用程序模拟浏览器，否则它将能够向任何 URL 发出请求。
需要 CORS 和同源策略，因为浏览器不会隐式信任它访问的网站以向其他网站发出请求。它们不保护源站点，它们保护接收跨源请求的站点。这就是允许的来源取决于目标服务器的原因。
如果没有这些政策，重复加载网站的简单脚本可能会通过广告网络或脚本注入进行分发，然后任何加载脚本的浏览器都会导致对网站的拒绝服务攻击。使用 CORS 和同源策略，浏览器将限制此脚本的影响。
CORS 提供的另一个重要保护是防止Cross-site request forgery。它可以防止站点向另一个站点发出某些类型的请求。这些请求将使用任何先前创建的令牌（例如会话令牌）发出。
CORS 示例：
网络浏览器从www.example.com 加载页面。该页面包含一个向www.example.org 发出请求的脚本。请求的来源是www.example.com。浏览器要么发出请求，要么首先发送OPTIONS 请求（预检请求）。当www.example.org 的服务器收到来自www.example.org 以外的来源的请求时，它会以响应标头Access-Control-Allow-Origin 进行响应，该响应标头告诉浏览器允许发出请求的来源。它还可以响应其他标头，例如 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers，这些标头可以限制允许的请求类型。当浏览器被告知允许哪些来源时，它将阻止来自不允许来源的未来请求。
【讨论】：
实际上两者兼而有之。您的浏览器将阻止 CORS 请求，除非请求的来源（即引用 URL 域）在目标的白名单中，或者目标批准所有请求而不管来源。
在这两种情况下，都添加了所需的标头 (Access-Control-Allow-Origin)，它告诉浏览器可以将请求发送到目的地。
这样可以确保有恶意的人无法在用户不知情的情况下将请求发送到另一个域。
【讨论】：