HTTP 方法“PATCH”可以跨代理等安全使用嗎？

Question

假設我的服務器公開了一個基於 HTTP 的 API，它使用RFC 5789引入的PATCH方法。 使用此方法時，位於公司防火牆、代理、緩存、家長控制過濾器等之后的客戶端（瀏覽器或其他）是否可能會遇到任何問題？ 如果是這樣，這種可能性有多大？

鑒於PATCH不是原始 HTTP 規范的一部分，而是稍后引入，我可以想象某些程序會因為“無效”方法而簡單地拒絕此類請求。 另一方面，我希望這樣的軟件只是簡單地通過一切，最多對某些 HTTP 方法（例如POST應用一些限制（例如，不緩存其結果）。

請注意，我不詢問服務器端或瀏覽器內的PATCH支持，而只詢問客戶端和服務器之間我既不知道也不控制的組件。 此外， PATCH本身是否是 API 的一個好主意的問題超出了這個問題的范圍。

Answer 1

這個問題的答案是一個移動的目標。 隨着時間的推移和 PATCH 變得越來越流行或越來越不流行，網絡中的系統可能支持也可能不支持。

通常，只有關心 HTTP 動詞的網絡實體才是OSI 級別3 (IP) 及以上設備（防火牆、代理）。 其中一些是“愚蠢的”，因為它們不檢查 OSI 級別 4 (TCP)。 其他人是“聰明的”，可以執行協議級別的執行。 例如，它們將阻止您打開端口 80 並發送 STMP 消息。

即使設備是“智能”的，它仍然可以配置為允許或不允許更不常見的 HTTP 動詞，如 PATCH。 因此，現在我們必須考慮托管設備的組織的安全狀況。 像星巴克和機場這樣有開放 wifi 的地方可能非常嚴苛，並且會鎖定安全。 與某些公司相同，尤其是當他們處理敏感數據（財務、個人信息）時。

結果是，根據用戶的人口統計，如果您沒有回退機制，PATCH 可能會出現問題。 我認為以下域中的受限用戶更有可能出現問題：敏感的企業環境、學校、軍事組織。