我正在尝试了解如何使用 restful 客户端为经过身份验证的用户实现安全性。我遇到麻烦的场景是如何阻止用户更新不属于他自己的购买，因为 restful 客户端将购买 id 传回。对于熟练的用户，产品 ID 很容易被篡改。我对被夹在中间并不真正感兴趣，因为使用 https 可以防止或减轻它。我对尝试更新不属于他们的内容的用户非常感兴趣。
您如何防止其他世界发生此类攻击？ Web Parameter Tampering
【问题讨论】：
标签： rest security web-applications authorization rest-security
您面临的问题称为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 的原则，只要它们对您的应用程序有意义”
【讨论】：