So I’ve been discussing the whole error message thing with two guys on the IIS team at Microsoft. Their opinion is that 403 would in fact be the most appropriate error code to issue. Their reasoning for using 404 is that “the client has no need to know” what the error is – simply that there has been an error. They say that it’s a security choice to return 404 as it gives the client “the least amount of information”.
I can see where they are coming from – if someone asks you where your safe is, you don’t tell them. However, if you’re going to be an HTTP server you have to play by the HTTP rules. I don’t agree that it’s none of the client’s business what the error is – it’s not a web server’s job to play judge and jury.
It’s slightly frustrating in that I can see that there’s probably little middle ground. You either have to be aggressively secure (or attempt that stance) or be completely transparent. This is one of those rare cases when the need for security gets in the way of those legitimately using a system. So it’s more ‘boooo!’ to the hackers than ‘boooo!’ to Microsoft. But I still don’t like it.
Here endeth my grumble.
Comments
There is a reason why relatively no one uses IIS for serious web servers... You never know what is really going on with the server and it is really difficult to find out. Cryptic error messages should be patented by Microsoft - although that system error message with a bomb icon from Apple is probably the funniest one going.
The whole culture at Microsoft on security is scary.. do they think not providing proper error messages will protect the server?
If IIS is truely secure and properly locked down, I’m not sure why it should matter. Security by obscurity.
Security by obscurity is pointless as the past month of bugs have demonstrated.
500 - Internal Server Error
501 - Not implemented
or even
503 - Service Unavailable
These errors will make end users happy knowing they can’t fix it and it isn’t their fault. And it remains secure.