我试图了解如何使用restful客户端为经过身份验证的用户实现安全性。我遇到麻烦的情况是如何阻止用户更新自己的购买而不是他自己的购买，因为宁静的客户通过了购买ID。对于熟练的用户，产品id可以容易地被篡改。由于使用https可以阻止或减轻它，因此我并不感兴趣。我真的对试图更新不属于他们的用户感兴趣。
你如何防止其他世界的此类攻击？ Web Parameter Tampering
答案 0 :(得分：5)
您遇到的问题称为authorization。一旦用户authenticated，授权就授予他访问特定资源的权限。 REST方案中的授权应该在服务器端实现。
假设用户Bob尝试通过向/purchases/1端点（提供适当的有效负载）发送经过身份验证（例如，使用基本HTTP身份验证，授权会话cookie等）POST请求来修改购买资源。验证Bob是否允许修改实体是服务器的职责（例如，通过检查是否真的是Bob进行了购买）。如果授予了权限，则服务器继续执行操作并以2xx success HTTP status code响应。否则将返回403错误代码，通知用户无权修改给定的购买。
一旦建立授权机制，就会出现另一个问题：用户发布恶意输入以试图欺骗和克服授权机制。这触及了一个非常广泛的Web应用程序安全主题。有很多已知的针对webapps的攻击（例如injection attacks）以及更多防范它们的方法。测试安全漏洞的应用程序称为penetration testing。值得一提的是，有自动化工具可以执行此类测试（以及执行此类攻击的自动化工具）。
总的来说，你已经触及了一个非常广泛的主题，并且没有办法用SO答案来解释百万分之一。将此答案作为您在该地区进行调查的起点。
当服务器上没有应用程序状态时，API是无状态的（而不是资源状态）。 Click here可以很好地解释这两者之间的区别。关于无国籍状态（特别是在身份验证环境中）有很多讨论 - 查找SO或Google。
简而言之，鉴于当今的大型分布式系统，REST中的无状态身份验证非常重要。此类环境中的服务器端应用程序状态在群集环境中的多个节点之间共享时可能会导致可伸缩性问题。这就是为什么建议将应用程序状态完全设置为客户端。我知道一开始可能会让你感到困惑，尤其是在我的答案中你已经阅读了服务器应该授权用户操作之后。 Here是无状态身份验证实现（数字签名的自包含会话令牌）的示例。
但不要害怕 - 实际上，大多数系统都存储服务器上至少部分应用程序状态（AFAIK Google在他们的系统中执行此操作）。就像this answer中所述：
“REST不是宗教信仰（...），只要符合REST的原则，就应该遵循REST的原则”