Pregunta

Consider animals being some REST resources. User has animals assigned to him.

The endpoint /api/animals/{animalId}/feed is used to feed a given animal by the authenticated user.

User should not be able to feed animals he does not own. What HTTP status code should be emitted in such a scenario?

400, 401, 403, 404, something else?


Also, should the situation where passing animalId that does not exist, e.g. 123456789 be distinguished from the situation where animalId does not belong to the logged in user?

I personally feel like I should return 404 in all cases.


This seems like a typical REST design situation, so I am wondering how experienced devs would solve it.

¿Fue útil?

Solución

400, 401, 403, 404, something else?

If the server refuses to apply the request, and wants to call attention specifically to the request's Authorization headers, then the appropriate status code is 401.

403 is similar, but less specific - once again, it indicates that the server understood the request, but won't apply it; the difference is that this status code can be used for problems unrelated to authentication.

(Historically, there has been a bit of drift in the meaning of 403. Both RFC 2068 and RFC 2616 state that changing the authorization will not help, but in RFC 7231 that claim is relaxed.)

That said, for security reasons you may want to be conservative about what information you allow an attacker to collect about your resources - if you help the attacker discover where the secret documents are, you are also inviting the attacker to concentrate their attacks on the secrets.

The HTTP standard explicitly allows that you may use a 404 status code (with an appropriate message) to make things harder for attackers

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

Licenciado bajo: CC-BY-SA con atribución
scroll top