我有一個簡單的安全同站點跨源設置，例如：
前端：https://www.example.com 應用程式介面：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 憑證。
但由於某些原因，它們的憑證不會被替換，它們的 access-controll-allow-origin 標頭不會在 api 請求中被刪除。
到目前為止我可以發現我們和 IMDB 之間唯一的區別是他們使用傳輸層安全協定1.3在他們的要求中，我們使用傳輸層安全協定1.2（透過AWS API網關）
到目前為止，我找到的線上幫助僅建議客戶在其網站上切換 Bitdefender 中的該功能，如果這種設定適用於 IMDB，我發現很難接受（好吧，也許他們已被 Bitdefender 列入白名單）
我還將其報告為 Bitdefender 作為“誤報”線程識別，但沒有任何返回。
我還可以尋找其他想法嗎？
答案1
Bitdefender 團隊非常有幫助。事實證明，當 Bitdefender 處於活動狀態時，它會降級為http/1.1協定.我們的伺服器沒有為 http/1 傳回「Access-Control-Allow-Origin」標頭，而只為 http/2 傳回「Access-Control-Allow-Origin」標頭。即使沒有 Bitdefender，我也可以透過使用
--http1.1帶有活動標誌的curl 或使用--disable-http2.我們正在使用AWS API網關在我們的設定中，經過更多谷歌搜尋後，我發現 AWS 正在解析 http/1 的請求標頭略有不同。
標頭。氧rigin 與標頭。哦里金
我們使用原始值來建立正確的回應標頭，因為我們期望小寫，所以我們基本上找不到該值。是的，只是一封信，花了我好幾天的時間。透過簡單地添加這個後備，它就起作用了：
const origin = headers["origin"] || headers ["Origin"]
感謝 Bitdefender 的提示！