我有一个简单的安全同站点、跨源设置，例如：
前端：https://www.example.com API：https://api.example.com
在这两个域上，我们都使用由 Amazon (AWS ACM) 颁发的 SSL 证书
我们的一些客户安装了 Bit Defender Total Security，它可以阻止对我们自己的 API 的 API 调用，即使GET是不涉及任何花哨的凭据/cookie 交换的简单调用。
我发现 Bitdefender 删除了access-control-allow-origin实际 XHR 请求中的标头；OPTIONS对 api 的调用仍然正确具有标头。
当我禁用该功能时“在线威胁预防的 Web 保护 > 加密 Web 扫描“在 Bitdefender 中重新启动 Chrome，它的工作正常，并且GET对 api 的调用正确返回access-controll-allow-origin=https://www.example.com
如果 api 位于同一个域上，例如，则不会发生此问题，https://www.example.com/api这表明这也是 Bitdefender 的 CORS 相关行为。
阅读此功能的描述后，我认为 bitdefender 可能不喜欢我们的证书，我用 LetsEncrypt 证书替换了我们的 AWS 证书；甚至不是通配符证书；仍然是同样的问题。
我还注意到 Bitdefender 用他们自己的本地证书替换了我们的证书，充当中间人，可能是为了扫描请求。
我不明白的是，例如www.imdb.com与他们有类似的设置api.graphql.imdb.com他们也使用 AWS Certs。
但由于某些原因，他们的证书没有被替换，并且他们的 access-controll-allow-origin 标头没有在他们的 api 请求中删除。
到目前为止，我发现我们和 IMDB 之间的唯一区别是他们使用TLS 1.3在他们的请求中，我们使用TLS 1.2（通过 AWS API 网关）
到目前为止，我找到的在线帮助仅建议要求客户在其网站上的 Bitdefender 中切换该功能，如果这种设置适用于 IMDB（好吧，也许他们被 Bitdefender 列入白名单），我很难接受
我还将其作为“误报”线程识别报告给 Bitdefender，但没有任何结果。
我还可以寻找其他什么想法吗？
答案1
Bitdefender 团队非常有帮助。事实证明，当 Bitdefender 处于活动状态时，它会降级为http/1.1协议。我们的服务器没有返回 http/1 的“Access-Control-Allow-Origin”标头，而只返回了 http/2。即使没有 Bitdefender，我也可以通过使用带有
--http1.1标志 active 的 curl 或使用 启动 Chrome轻松调试此问题--disable-http2。我们正在使用AWS API 网关在我们的设置中，经过进一步的谷歌搜索后，我发现 AWS 对 http/1 的请求标头的解析略有不同。
标头。哦源与标题。o起源
我们使用原始值来创建正确的响应标头，但由于我们期望小写，所以我们基本上找不到该值。是的，只有一个字母，这花了我几天时间。通过简单添加此回退，它就起作用了：
const origin = headers["origin"] || headers ["Origin"]
感谢 Bitdefender 的提示！