OWASP（开放Web应用程序安全项目）有一些涉及Web应用程序开发各个方面的备忘单。本项目是非常有价值和可靠的信息来源。关于REST服务，您可以检查：https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

OWASP（开放Web应用程序安全项目）有一些涉及Web应用程序开发各个方面的备忘单。本项目是非常有价值和可靠的信息来源。关于REST服务，您可以检查：https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

我遇到过的关于REST安全性的最好的帖子之一是1 RainDrop。MySpace API也使用OAuth进行安全保护，您可以完全访问RestChess代码中的自定义频道，我对此进行了大量探索。这是在Mix演示的，你可以在这里找到帖子。

我有点惊讶的是，还没有提到带有客户端证书的SSL。当然，只有当您能够依靠证书识别用户群体时，这种方法才真正有用。但许多政府/公司确实向其用户发放了这些证书。用户不必担心创建另一个用户名/密码组合，并且在每个连接上都建立了身份，因此与服务器的通信可以完全无状态，不需要用户会话。（并非意味着所提及的任何/所有其他解决方案都需要会议）

正如twitt所说，AmazonS3是一个很好的模型。它们的请求签名确实具有一些特性（如包含时间戳），有助于防止意外和恶意请求重放。

HTTP Basic的优点是几乎所有的HTTP库都支持它。当然，在这种情况下，您需要使用SSL，因为通过网络发送明文密码几乎是一件普遍的坏事。使用SSL时，Basic比Digest更好，因为即使调用方已经知道需要凭据，Digest也需要额外的往返来交换nonce值。使用Basic，调用者只需在第一次发送凭证。

一旦确定了客户机的身份，授权实际上只是一个实现问题。但是，您可以将授权委托给具有现有授权模型的其他组件。同样，Basic的好处是，您的服务器最终提供了客户端密码的明文副本，您可以根据需要将其传递给基础架构中的另一个组件。

REST本身没有提供安全标准，但OAuth和SAML等东西正在迅速成为这个领域的标准。然而，身份验证和授权只是您需要考虑的一小部分。与web应用程序相关的许多已知漏洞非常适用于REST API。你必须考虑输入验证、会话破解、不适当的错误消息、内部员工漏洞等等。这是一个很大的问题。