PUT 和 DELETE 本质上并不是不安全的，例如，它们在许多REST 服务中使用时没有问题。

在我的实践中，与这些 HTTP 动词相关的主要问题（除了常见的身份验证和授权问题）是服务器操作员不知道它们的存在引入了HTTP 动词篡改的可能性。总之，这意味着访问控制是基于 HTTP 动词黑名单实现的，但该列表中缺少一些鲜为人知的动词，从而允许绕过访问控制。

我想指出，许多 Web 服务器实现了他们自己的自定义（有时未记录）HTTP 动词，所以这种“基于动词的访问控制”无论如何似乎都不是一个好主意。

HTTP 方法本身与安全性无关。像这样的方法DELETE /users/1也可以很容易地实现为POST /users/1/delete甚至GET /users/1/delete（GET 永远不应该有副作用，但这并不能阻止一些开发人员这样做）。

因此，您应该像对待任何其他 HTTP 方法一样对待它们。GET 不应更改服务器状态，因此通常您只需要验证客户端是否具有对所请求资源的读取权限。PUT 应该用于完全就地更新资源（尽管它们通常也与 PATCH 动词类似地使用），因此您应该确保客户端具有执行此操作的权限。同样，应发送 DELETE 以请求删除资源。因此，您需要确保用户有权这样做。

简而言之：将动词视为用户希望执行的操作类型的描述符。根据您的特定应用程序的安全参数的要求，验证并授权他们执行这些操作。

来自 OWASP 测试指南：

其中一些方法可能会给 Web 应用程序带来安全风险，因为它们允许攻击者修改存储在 Web 服务器上的文件，并在某些情况下窃取合法用户的凭据。更具体地说，应该禁用的方法如下：

• PUT：此方法允许客户端在 Web 服务器上上传新文件。攻击者可以通过上传恶意文件
  （例如：通过调用 cmd.exe 执行命令的 asp 文件）或简单地将受害者的服务器用作文件存储库来利用它

也就是说，实际上您需要注意两件事。

• 如果您想允许这些用户制作新内容，请确保您只允许您信任的经过身份验证的用户使用。在允许他们拥有 FTP 帐户的范围内，应该信任这些用户。
• 如果您允许他们更改现有内容，请确保您对其进行限制，以使他们确实只能覆盖某些现有资源而不能覆盖其他任何内容。

还要确保您使用的是 SSL/TLS。

用于记录：RFC 2616 超文本传输​​协议 HTTP/1.1 / Method-Section

REQUEST 是从客户端到服务器的请求，并没有过多说明服务器将对该请求执行什么操作；可能的方法不必在服务器级别实现。

因此，如果您访问 myserver.com 并要求“DELETE /blah”，myserver.com 可能会简单地说：“thanx，先生，祝您有美好的一天”。

9.6 放

PUT 方法请求将封闭的实体存储在提供的 Request-URI 下。

9.7 删除

DELETE 方法请求源服务器删除由 Request-URI 标识的资源。此方法可能会被源服务器上的人工干预（或其他方式）覆盖。客户端不能保证操作已经执行，即使从源服务器返回的状态码表明操作已经成功完成