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)?
2
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.
3