当我向我的应用程序中的端点发出请求时，在邮递员中指定原点 header 没有任何作用（javascript 和 nodejs）

Question

我目前的服务器文件设置如下：

export default createServer = (container) => {
  const env = process.env.NODE_ENV
  const allowedOrigins = process.env.ALLOWED_ORIGINS || ''
  const allowedOriginsArray = allowedOrigins.split(",").map(item => item.trim());

  const cors = Cors({
    origins: allowedOriginsArray,
    allowedHeaders: [
      'access-control-allow-origin',
      'authorization',
      'Pragma',
      'contact',
    ],
    exposeHeaders: []
  })
}

在这里，我将 origins 设置为来自我的 env 文件的字符串数组。（我已经查看了cors文档页面，我相信可能有错字，origins应该是origin。无论哪种方式似乎都没有什么不同）。

在我的邮递员请求中，为了测试它，我将来源 header 设置为“http://www.test.com”（这不是我在我的环境文件）。请求在应该失败时成功。我想知道我是否在邮递员中错误地测试了这个，或者我的代码中是否有错误。

Answer 1

浏览器强制执行同源策略，以阻止 Mallory 的邪恶网站向您的浏览器发送一些 JavaScript，这将向您的网上银行发出 Ajax 请求，并将您的信用记录发送给 Mallory。

CORS 用于放宽同源策略（以便网站可以将您与他们共享的数据的访问权限授予某些受信任的其他网站）。

Postman 不是浏览器。您不使用它来访问网站。它不执行嵌入在这些网站中的 JS。 Mallory 无法告诉它发出 HTTP 请求。只有你能做到。 Postman 不需要执行同源策略，所以它不需要。

您可以使用 Postman 发出带有来源 header 的 HTTP 请求。然后您的服务器可以发回适当的 Access-Control-Allow-Origin header。但是，Postman 除了将其显示在响应列表 headers.

之外，不会对它做任何事情。

它肯定不会放松同源策略，因为它一开始就没有强制执行。

Answer 2

The requests succeeds when it should fail.

这是对 Same Origin Policy and CORS 工作原理的误解。请求 不应该 失败，只是响应会或不会包含 浏览器 可以用来确定是否授予访问权限的信息到其中的信息到请求信息的来源。如果响应不允许请求它的源，浏览器 会阻止来自源的代码看到响应。

Postman 不是浏览器，不会这样做（尤其是因为它没有来源来测试响应）。

您无法在服务器端可靠地执行此操作，因为恶意行为者只会向您的服务器发送他们认为您的服务器想要的内容。重点是服务器回复信息，告诉浏览器谁可以访问该信息。

我们的目标不是让服务器发回的信息保密（这就是 SSL 和身份验证的目的）。这是为了防止用户存储的身份验证信息或活动会话被用于使用该用户的凭据窃取信息。它是这样工作的：

假设爱丽丝上网到银行 B 支付账单，当她的会话处于活动状态时，她还去检查某物的成本并访问恶意站点 X 以找出答案。恶意站点 X 希望爱丽丝恰好是银行 B 的客户，向银行 B 的网站发送请求以获取（比方说）爱丽丝的帐户信息。假设该请求是真实请求的完美模仿，那么银行 B 的网站很高兴 returns 信息——因为爱丽丝确实恰好登录了银行 B 的网站。哦不！

这就是 SOP 的用武之地。浏览器知道是 X 页面上的代码请求信息，并且知道它从 B 银行的网站请求信息。因此它会检查响应以查看响应是否明确表示“是的，可以与 X 共享”。由于响应没有这样说，浏览器阻止恶意站点 X 看到响应，他们窃取 Alice 信息的邪恶阴谋被挫败。

Answer 3

从您对另一个答案的评论来看，我认为您的想法是倒退的； Postman 可以添加 Origin，因为 Postman 是一种用于“伪造”浏览器发送的 http 请求的工具，并且不具备添加 Origin 的能力会使 Postman 成为一个糟糕的伪造者。某些服务器可能会使用 Origin，Postman 能够发送 Origin header 意味着无论服务器用它做什么，都可以进行测试。

总的来说，作为 browser-to-server 通信的 Origin 与 CORS 和 SOP 关系不大，后者是一种朝着“server-to-honest-browser”方向发展的安全机制。在请求中包含 Origin header 可能会导致服务器响应 CORS headers 但你不应该 hard-link 这两个概念，因为 Origin 也可以为非 CORS 请求发送，并且 CORS 不会特别需要 Origin header 中的任何信息才能工作

对于支持 CORS 的场景，服务器会说（在响应中 header）哪些网站应该使用它以及一个诚实的浏览器（就像大多数人一样，当他们安装最新的 Chrome 时）决定显示的页面是否应该从服务器获取数据。想象一下浏览器正在显示 delta.com 并且页面上的脚本试图从某个后端服务器获取一些数据。在它执行脚本想要的数据请求之前，浏览器会向服务器发出自己的请求以检查它是否正常；这是一个选项请求。如果服务器响应选项说“只有 acme.com 提供的脚本应该使用我”并且浏览器没有显示 acme.com，那么浏览器不会执行页面上的脚本想要的请求去做;相反，控制台中会出现一个错误，因为 delta.com 脚本需要数据，而浏览器在快速“向服务器耳语”后决定不执行该请求

使用不关心 CORS 请求的浏览器的恶意行为者无论如何都可以使用服务器。 Postman 就是这种“浏览器”的一个例子——它根据您的要求发出请求，根本不关心 CORS。如果您有兴趣让 Postman 像浏览器一样运行，您应该：

假装是delta.com
使用 postman 向 server.com（带有 Origin）发出 OPTIONS
Postman 在 A-C-A-O header
你自己的大脑决定不发出你最初想做的 POST 请求，因为你已经意识到你在假装 delta.com 而服务器只与 acme.com

这将是一个更准确的“邮递员假装像一个正常的日常浏览器”迭代

Origin 可以输入 CORS；服务器可以有 1000 个不同的站点，它愿意允许来自的请求。清楚地在每个响应中发送 1000 个站点名称（“如果您显示来自 acme1.com 或 acme2.com 或... acme999.com 的页面，请仅使用我”）将使响应 header 非常庞大，浏览器有上千个站点可供检查。如果服务器是智能的，它可以使用 Origin 来驱动响应；如果提交的“来源：acme547.com”在服务器知道的 1000 个站点的允许列表中，则服务器可以发送 仅那个 acme547.com 返回“请仅在以下情况下使用我。” header - 它也不需要发送其他 999 个站点。如果 Origin 来自 delta.com，那么它根本不会发送“请只使用我..”header，导致诚实的浏览器无法请求

当我向我的应用程序中的端点发出请求时，在邮递员中指定原点 header 没有任何作用（javascript 和 nodejs）

Specifying the origin header in postman does nothing when I make a request to an endpoint in my application (javascript and nodejs)

javascript

same-origin-policy

node.js

cors

postman