HTTP方法“PATCH”是否可以在代理等跨域情况下安全使用？

Question

假设我的服务器暴露了一个基于HTTP的API，使用RFC 5789引入的PATCH方法。是否可能在企业防火墙、代理、缓存、家长控制过滤器等组件使用此方法时会遇到问题？如果有问题，这种情况有多大可能性？

考虑到PATCH不是原始HTTP规范的一部分，而是后来引入的，我可以想象一些程序会因为“无效”的方法而拒绝这样的请求。另一方面，我希望这样的软件只是简单地通过所有请求，并且至多对某些HTTP方法（如POST）应用一些限制（例如不缓存其结果）。

请注意，我不询问服务器端或浏览器内部的PATCH支持，而仅关注客户端和服务器之间的组件，这些组件我既不知道也无法控制。此外，本问题不涉及PATCH本身是否适合API的问题。

- Jens Bannmann

Answer 1

这个问题的答案是一个不断变化的目标。随着时间的推移，PATCH 可能会变得更受欢迎或不受欢迎，网络中的系统可能支持也可能不支持它。

通常只有关心 HTTP 动词的网络实体才会是 OSI 层 3（IP）及以上设备（防火墙、代理）。其中一些是“愚蠢的”，因为它们不检查 OSI 层 4（TCP）。其他人则是“聪明的”，可以进行协议级别的执行。例如，它们将防止您打开端口 80 并发送 STMP 消息。

即使设备很“聪明”，它仍然可以配置为允许或不允许更不常见的 HTTP 动词，如 PATCH。因此，现在我们必须考虑托管设备的组织的安全形势。像星巴克和机场这样的开放式 WiFi 地点可能会非常严格地锁定安全性。同样，一些公司特别是那些处理敏感数据（金融、个人信息）的公司也是如此。

总之，根据用户的人口统计信息，如果没有后备机制，PATCH 可能会成为一个问题。我认为以下领域的受限用户更有可能遇到问题：敏感的企业环境、学校、军事组织。

- Edgar