Correct HTTP status code when resource is available but not accessible because of permissions

Question

I am building a RESTful protocol for Dynamic Carpooling applications, for my Computer Science thesis.

In the Protocol I also have to formally specify the HTTP status code for each operation. I've got this "privacy related" problem. Suppose the following:

GET /api/persons/angela/location

Retrieves the current position of user "angela". It is obvious that not everybody should be able to obtain a result. Only angela itself and a possible driver that is going to pick her should be able to know it.

I can not decide whether to return a 404 Not Found or a 401 Forbidden here.

Any hints? What would be the best one and why?

Stackhouse

A 404 is completely incorrect here as it indicates the record doesn't exist at all. – Kistner

Answer 1

According to Wikipedia (and RFC 2616), a 401 code is used when a page exists but requires authentication; 403 is for a page where authenticating won't change anything. (In the wild, 403 usually means the permissions on something are wrong, whereas a 401 will prompt the user for a username/password). 404 is for where the document simply doesn't exist.

In your case, it seems like 401 is the most appropriate code, since there is some way of authenticating the users who DO have access to the page.

Reversible

Good one! Quite the whole protocol operations require authentications. I've got cases in which resources are available but cannot be retrieved because of user rights and also cases in which resources are not available because the were previously deleted. Both cases are under authenticated operations. Would you go for a 401 in the first case and a 404 for the second case? Therefore: resource exists but you can not access it -> 401 resource does not exist -> 404 – Stackhouse

Yes, if a resource was deleted, a 404 is appropriate if an attempt is subsequently made to access it. – Reversible

Good answer, but I'd prefer "according to Wikipedia" to say "according to RFC 2616" tools.ietf.org/html/rfc2616#section-10.4.2 ;) – Elis

But, giving 401 response exposes the fact that file actually exists. – Sheepdip

incorrect, the RFC you cited explains that if the reason for refusal is not given, the 404 error can be used. (in case the user is already logged in, there is no error 401, but 403, and in this scenario, if there is no explanation in the response of the reason for the error, 404 is possible to be used). Microsoft, for example, returns a 401 error when accessing a resource that requires a login. If the login is done, but the user does not have permission, then the 404 error can be displayed depending on the context. rfc-editor.org/rfc/rfc2616#section-10.4.4 – Quad

Answer 2

If authorization credentials are provided in the request and the requester does not have permissions to access this resource then you should return 403.

If no authorization credentials are provided in the request then you should return 401.

Cottony

If authorization credentials are provided in the request and the requester does not have permissions to access this resource then you should return 401 not a 403. RFC 2616 explicitly says that for a 403, "Authorization will not help and the request SHOULD NOT be repeated" (tools.ietf.org/html/rfc2616#section-10.4.4). So if there are valid credentials that would give permission to access the resource, don't return a 403. – Elis

@Elis You are absolutely correct. My answer is wrong. Hmm, you learn something new every day. – Cottony

No worries. How about having a stab at my spin off question https://mcmap.net/q/183461/-is-it-ok-to-return-a-http-401-for-a-non-existent-resource-instead-of-404-to-prevent-information-disclosure/445073 :) – Elis

In my scenario a certain sort of db resource is available whether or not the requester is logged-in. BUT that resource can be set, in terms of that website, as 'Private' or 'Public'. Authorization credentials are irrelevant in this scenario; the non-standard status of "It's set Private" is the determiner, so I believe the appropriate status to send back in this scenario is HTTP 403 / Forbidden. – Brevity

401 = Not logged in -- 403 = logged, but without permission. See: auth0.com/blog/forbidden-unauthorized-http-status-codes. You are correct in the answer, and the comment has led you to think that you are not, but you are originally correct. – Quad

Answer 3

Definitely NOT 404. 404 is just Not Found.
401 is access denied.
403 is forbidden.

I would go with 401

Equipoise

401 is not access denied. It is "not logged in and login required". – Hadlee

@EricStein According to RFC 2616 (tools.ietf.org/html/rfc2616#section-10.4.2), "If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials." So 401 is in fact access denied. – Toponym

Answer 4

To me I will use 400 Bad request.
Because my application will not go unaccessable resources in programmatically.
Filtering users permission and hide unaccessable resources is good user experience in my opinion. If my server got unaccessable request which means some person trying to do something.
That is why I choose 400 - Bad request in my applications.

Kotz

I disagree. responding with a 400 Bad Request for valid requests is a broken API. 400 Bad Request means that something is wrong with the request. Anyone using your API will think the request is wrong, when in reality, the request is right, this is literally what 401 and 403 are for. It makes things easier to debug. – Mozell

As I said normal users never request unaccessable resources. If my server got unaccessable request which means some sneaky person trying to hack unaccessable resources. Also I will never respond error code for valid requests. – Kotz

You should generally never make assumptions about what normal users will and won't do. Authentication is not necessarily part of the request. If you're worried about sneaky people, the correct solution is not intentionally breaking the HTTP (security by obscurity). The correct solution is to put up a firewall in front of your API, so that the sneaky people can't even probe your API in the first place. – Mozell

I never said anything about Authentication. There are many different departments and many different users role in my application. Because my client is very big corporation. In my application lots of private data here. Because of that every user is thread to me. Who knows their computer hacked or not... In front end application is never access unaccessable resources in programmatically. So in server side I will validate every request by user, make sure it is valid request. If is not stop executing and respond 400. – Kotz

Answer 5

If the user has valid credentials, but does not have permission to view the resource, error 403. If he is not authenticated, and needs to be, error 401. According to rfc https://www.rfc-editor.org/rfc/rfc2616#section-10.4.2, error 401 indicates missing credentials, and error 403 indicates other authorization issues, such as not being granted permission despite being logged in. But it should only be used if you explain the reason for the refusal (lack of permission for example), if no explanation for the refusal of an authenticated user is provided, you can use the 404 error, according to the RFC.

Quad

Answer 6

At the date of this post, 13 Nov 2023, the current RFC may recommend 403 for insufficient permissions.

https://datatracker.ietf.org/doc/html/rfc9110#name-403-forbidden

Heyman