3

So I have different seniors taking different positions on this. Some saying hide nothing, those codes are there for a reason. Others saying to hide most status codes, reducing the number to a much smaller group (like only 400 and 404). Even RFC 2616 suggests a few substitutions are allowed (403 being treated as a 404 for a resource the web server will never deliver and will never explain why).

I'm not talking about the error page the user sees. Of course that should look nice for the user and should not dump a stack trace, ect. I'm talking about the http status included in the response. Meaning if they try to access a resource they aren't authorized for, instead of giving a 401/403, actually making the response be a 404 so that there is no way to know there was something there they weren't authorized for.

Is there a clear cut answer on which is the better practice (kinda like how it is best practice to not reroll your own password hashing)?

Improve this question
2
  • Regarding your particular example: I would not hide the fact that you need to be authorized in order to access a page. Imagine you are coding a web API like that and a client developer trying to interface that API had to guess around if the resource really does not exist or if they made a mistake with passing on the authentication credentials. Also in case of ordinary web pages: what if your authorized user saved a bookmark to a page that needs authorization, logs out, clicks that bookmark and sees "404"? That will only cause problems for you.
    – tiguchi
    Commented Oct 22, 2014 at 19:20
  • 4
    This is not authoritative, so I won't make it an answer. At my previous employer, we were required by a customer to make our application return a 200 status for everything, including errors, for security reasons. The argument to hide them was that security scanners can use status codes to look for the existence of vulnerabilities like /cgi-bin/someVulnerableProgram.exe. By never returning a 404 for anything, they can't map/enumerate our URL space. It was a huge mistake. A lot of legitimate code broke when we changed it.
    – Brandon
    Commented Oct 27, 2014 at 14:52

1 Answer 1

Reset to default
3

No, there's no pre-defined set of "must-have" HTTP status codes. Out of the 40-or-so status codes listed in RFC 2616 I put together a list of codes that, in my experience, are the ones you should consider using to their full extent.

200, 201
302, 304
400, 403, 404
500

8 status codes, not that bad. Depending on your particular application, there are others that may be helpful (202, 503, etc) but the majority of status codes (particularly in the 1xx/4xx/5xx groups) are only useful in specific conditions or will be handled by your application server.

In short, use the codes that match the semantics of your application's API.

To address your specific example of replacing 401/403 with 404, that's a special case where revealing the existence of a resource is itself a security risk. There are few applications where this behavior is necessary.

GET /users/admin/edit should return 403.

GET /docs/top-secret/missile-launch-codes should return 404.

Improve this answer
3
  • I think the issue here is that part of my organization has the opinion that what is good for the missile launch codes is good for the administration edit features. Also, shouldn't admin/edit be a 401, not a 403?
    – Lawtonfogle
    Commented Oct 27, 2014 at 13:33
  • 4
    @Lawtonfogle Depends. 401 means "you might have access if you authenticate" and requires the WWW-Authenticate response header. 403 means "you don't have access, period."
    – Eric
    Commented Oct 27, 2014 at 13:45
  • +1 for "there are few applications where this behaviour is necessary"
    – Benjamin Hodgson
    Commented Jan 25, 2015 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.