4

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.

weno
  • 241
  • 1
  • 5
  • What information would be leaked by telling anyone that an animal exists but is inaccessible? E.g. if the IDs are sequential numbers would it be a problem that anyone can determine how many animals there are in total? But yes, unless you're sure that leaking such information would be safe, it's better to just return a 404. – amon Jan 17 '21 at 12:52
  • Does this answer your question? [Http Status Code When Downstream Validation Fails](https://softwareengineering.stackexchange.com/questions/399962/http-status-code-when-downstream-validation-fails) – gnat Jan 17 '21 at 17:36
  • 1
    Is your data tenanted or just access controlled? In our system, user data is tenanted, so an endpoint with `/api/animals/{animalId}/feed` for an `animalId` not owned by the current user would get you a 404, because it doesn't exist for the current user. If the animalId exists for the current users tenanted data set, but they don't have permission to feed or access the animal (ie the animal exists in the current users tenanted data set, but they specifically dont have access to it), then its a 401. So the setup of the system is important here, is what I'm trying to say. – Moo Jan 17 '21 at 20:47
  • @Moo “feed” doesn’t seem quite suitable for a REST resource anyway. – gnasher729 Jan 17 '21 at 23:31
  • @gnasher729 its an action, and REST is a lot of things to a lot of people, so no judgement there. – Moo Jan 18 '21 at 00:05

1 Answers1

4

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).

Community
  • 1
VoiceOfUnreason
  • 32,131
  • 2
  • 42
  • 79
  • 2
    Error 401: “Do you know who I am?” “No, I don’t”. Error 403: “Do you know who I am?” “I don’t care who you are”. – gnasher729 Jan 17 '21 at 23:34
  • @gnasher729 It should rather be: Error 403: "Do you know who I am?" "Yes and you cannot access the resource", shouldn't it? – Tomasz Posłuszny Mar 03 '21 at 19:10