在CORS請求的POST之前使用OPTION請求的原因是什麼？

Question

什麼是背後的實際POST，UPDATE，PUT或DELETE請求時不同的域調用之前發送OPTION請求的原因？ （所以CORS請求）我知道它應該檢查服務器是否可以處理真正的請求，但爲什麼不立即發送真正的請求？

一些原因，我曾經想過：

1. 看看該方法支持
2. 發送真正的請求將返回相同的狀態代碼，所以 無需首先發送OPTION請求。
3. 檢查用戶是否允許發送請求
   • 沒有任何意義，因爲沒有身份驗證頭與OPTION發送請求在服務器上
4. 防止重負載
   • 沒有意義，因爲在處理數據之前檢查授權規則。
5. 要檢查是否請求頭和原產地允許
   • 這是它是如何工作了，但是又爲什麼不直接發送請求，我們可以從實際的請求讀取錯誤。
6. 禁止發送POST數據，如果它不會被處理
   • 這是唯一的原因是什麼是有效的。使用選項請求將阻止不必要地將發佈數據發送到服務器。不過，我認爲在99％的時間內這不是問題，因爲只發送一小塊數據。

有人可以提供一些線索上的原因，瀏覽器廠商調用不同的域時實施OPTION請求？

Answer 1

CORS基本上是一個瀏覽器安全功能，而不是服務器端。

默認情況下，瀏覽器不會允許某些交叉源請求。您正在與之通話的服務器可以發佈使用交叉源請求是否安全，但它是理解並使用該信息的客戶端，因此提供的不是服務器的保護。

因此，對於GET請求，您可以獲取資源，檢查CORS頭，然後根據頭確定是否處理它。很好很簡單。

對於POST（或其他更改）事件並不那麼簡單。你做POST請求，服務器處理它（記住服務器不關心CORS，只關心瀏覽器）並且發回響應。瀏覽器發現CORS沒有啓用並且忽略了響應，但是由於這一點太晚了 - POST請求已經在服務器端進行了處理，並且所有阻止的都是顯示處理結果。例如，對於在線銀行應用程序來說，惡意請求轉移資金意味着資金將被轉移，但您的瀏覽器將忽略「轉移資金成功」的迴應 - 重大損失是在資金消失和惡意請求無論如何，可能都會忽略迴應！

所以你不能發送請求，直到你知道什麼CORS頭將在響應 - 這需要發送請求！雞和雞蛋的情況。

因此，瀏覽器發送一個OPTIONS請求到不像一個POST請求改變任何可能同一個地址，但確實返回CORS頭。之後，瀏覽器知道發送真實請求是否安全。

而順便說一句，服務器沒有實現CORS安全的原因是，它很容易改變引用頭，因此它不會提供任何保護。服務器將具有其他安全功能（例如，檢查會話有效並被授權發出請求），但是CORS旨在防止的攻擊是這些攻擊不起作用的攻擊（例如，用戶是已登錄到其在線銀行另一個選項卡）。