我们公司(以及其他一些公司)保持 PCI 合规性。作为我们最近的安全审核的一部分，我们的基础设施团队和审核员确定应完全禁用 OPTIONS header ，因为它构成了安全威胁。
我们在 Angular 6/7 网站上使用 .NET Web API(在多个子域上)。现在禁用 OPTIONS header 后，来自 Angular 的预检调用将被拒绝，并且我们的应用程序在对另一个子域的第一次 API 调用时失败(例如身份验证，这是我们的第一个功能之一，位于 auth.mycompany.com 上，我们的应用程序位于 app 上) .mycompany.com)。
我已经阅读了相当多的内容(如果有人将其标记为重复项，如果它能带来解决方案，我会很高兴:)但是，我还没有找到任何可行的解决方案。大多数文章都要求将有效的 OPTIONS 调用列入白名单( Why is HTTP Options request insecure 和 https://security.stackexchange.com/questions/138567/why-should-the-options-method-not-be-allowed-on-an-http-server 是两个示例)或在同一子域上设置代理( Preflight CORS requests with Basic Authentication in Angular 2 )。
我的问题是，有没有办法配置 OPTIONS header ，让我们能够通过安全扫描，同时仍然允许来自 Angular 的 CORS 调用？
最佳答案
Our company maintains PCI compliance (along with a few others). As part of our most recent security audit it was determined by our infrastructure team and auditors that OPTIONS headers should be completely disabled as it posed a security threat.
我同意跨所有域的所有 OPTIONS 的广泛 block 是有效的安全默认值，但它们应该允许某些 OPTIONS 请求到达正确的服务器，因为它是 HTTP 规范的一部分。
一些安全团队会按照标准做法阻止所有 POST 请求，您必须请求允许哪些 POST 请求进入网络。
我们无法告诉您这是否是一项好政策。
My question is, is there a way to configure the OPTIONS header that will allow us to pass our security scans and still allow our CORS calls from Angular?
这是向另一个域发出请求时网络浏览器执行的标准安全检查。这是你无法改变的。
这是您此时的选项列表
- 请求允许相关网络服务器使用这些选项。告诉安全团队，服务器将被修改以产生本质上严格并确保安全的 OPTIONS 响应。
- 在同一域上托管 Angular Web 应用程序，以便浏览器不会发出 OPTIONS 请求。
- 更改所有 API 调用，以便仅向 API 发出不带正文的 GET 请求(空 GET 请求不受 OPTIONS 预检请求的影响)。
- 在与 Angular 应用程序相同的域中创建 API 代理，并让该代理对其他域进行所有 API 调用(后端服务器不发出 OPTIONS 请求)。
在实现上述任何操作之前，请先咨询您的安全团队。
关于.net - Web 服务器上禁用 header ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53285090/