2013-07-25
An important thing about security issues in HTTP error responses
Although I mentioned this in passing in my first entry on this subject, it is worth talking about how Unix login attempts differ from HTTP requests for most websites. The obvious difference is that innocent people make requests for bad URLs much more frequently than they use bad logins on Unix machines. The second difference can be put in two ways, either that people make plenty of unauthenticated requests or that (unlike in Unix) it is not necessarily obvious when you need to authenticate to do something unless you're told explicitly.
Unless you're running an unusual website, the overall goal of your site is to be useful to people. Being secure is part of being useful but not the only part (otherwise you wouldn't have a website at all). The most secure approach is clearly to pick one error code and one generic set of error text and present that to users regardless of what's wrong. But this is not really useful to actual people who are making innocent mistakes. By extension, more useful error responses are for those actual people (and sometimes actual software) and the goal is thus to pick responses that are useful to people while leaving you as secure as possible.
There is clearly a balance here and where you put it depends on a lot of factors. As with all security balance situations there is no single global right answer. If you're running a mostly public site with low-sensitivity information that has unpredictable (by users) areas of access restrictions, you're likely to tilt strongly towards giving site visitors a lot of information in error responses. Since this describes a lot of websites it's perhaps no surprise that HTTP itself is biased in this direction (as show by even having separate error codes for this).
(Note that error codes are only one part of the information you give people in HTTP error responses. Don't assume that an attacker is, eg, ignoring the actual text of those responses.)