我已经使用 Spring MVC 3.1 创建了一个 Web 服务 (RESTful)，并添加了 Spring 安全性。其中一个端点是/users/{id}，它应该只对管理员可用。但是，当且仅当检索到的资源的用户名与登录用户的用户名匹配时，/users/{id} 也可供用户使用。这可以通过使用 @PostAuthorize 注释来解决。
现在，如果用户访问/users/999（不是登录用户），我应该返回 HTTP 状态 404 还是 HTTP 状态 403？目前我正在执行 404（未找到），但它应该是 403，因为用户不应该能够访问它吗？
如果是这样，当您依赖 @PostAutorize 注释时，您将如何做到这一点？
@PostAuthorize("returnObject.username == principal.username and hasRole('ROLE_USER')")
【问题讨论】：
标签： java spring jakarta-ee spring-security
我会使用 404，因为资源是否存在不是非管理用户应该拥有的信息。这甚至在the HTTP specification with regard to code 403 中都有介绍：
服务器理解请求，但拒绝执行。 授权将无济于事，并且不应重复请求。 如果请求方法不是 HEAD 并且服务器希望 公开为什么请求没有得到满足，它应该描述 实体拒绝的原因。 如果服务器不希望 将此信息提供给客户端，状态码 404 （未找到）可以代替。
（我的重点。）
如果您改用 403，则在回复对不存在资源的非管理员请求时必须使用 403，否则您的实现会将信息（哪些用户存在和不存在）泄露给非管理员不应该拥有该信息的管理员用户。
有一个使用 403 的论点（即使用户不存在），但我认为 404 将其排除在外。但是，无论您使用哪种方式，在回复非管理员用户对他们自己以外的用户页面的请求时，始终使用它，以避免信息泄露。
【讨论】：
您应该使用 403，因为资源可用但不允许用户使用。 HTTP 403 规范明确提到：
服务器理解请求，但拒绝执行。 授权将无济于事，并且不应重复请求。如果 请求方法不是 HEAD 并且服务器希望公开 为什么请求没有被满足，它应该描述原因 对于实体的拒绝。如果服务器不想让 此信息可供客户端使用，状态码 404（不 Found) 可以代替。
Web 服务器可能会返回 403 Forbidden HTTP 状态代码作为响应 来自客户端的对网页或资源的请求，以表明 服务器拒绝允许请求的操作。换句话说， 可以访问服务器，但服务器拒绝允许请求 访问。
【讨论】：