I hope that you already know that users hate meaningless error messages. (Actually they hate all error messages – don’t we all!) So that’s one reason to not allow default messages to display in your web application.
But there is another important reason: security!
Read the error message
That’s something I often remind developers about on course. Read the error message so that you understand the error. But that doesn’t mean you should display the errors to everyone.
Of course, in an ideal world, your web application will not have errors. But until then, it is important that you write code to properly handle errors, and not just display the default internal error messages to the user.
Why? Because unlike the rest of us, hackers are very good at reading error messages. Why? Because there is a surprising amount of information in the error message.
Here’s a simple example of a standard HTTP 404 Not Found error.
Not Found The requested URL /page.html was not found on this server. Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80
That error tells the hacker the web server version, the OS and the code used. Now he (or she) can design a more effective attack.
The information disclosed via standard error messages may include valuable information such as the database system, database usernames, file system paths, and other useful configuration information. That might enable a hacker to target your system with the “right” code injection!
Find the balance
You have to find the balance between an error message that is helpful to the user, and an error message that is helpful to the hacker.
With a failed logon attempt, for example, your error can be:
Invalid username / password
If you use a more specific error, such as
Invalid password, you effectively tell the hacker that the username was valid.
Here are some useful sites for more information: