Keep error messages vague

- Hackers use the results of their actions to improve their chances of success. Imagine that a hacker visits a standard login page on a website, and they try a user name and password. If the response is user name not found, then the hacker knows to try a different user name. If after a few tries the response changes to password not found, they'll know they've made some progress. And they've found a valid user name. A more secure approach is to return an identical login failed message in both cases. Don't tell a hacker when their actions are getting warmer or colder. They can just use that information to adjust their attacks. Give as little information back as necessary. This applies to all user messages but especially to error messages. These may be errors that you're expecting and handling like failed logins. Or they may be unexpected errors caused by bugs in your code. When developing a website, it's helpful to have error reporting enabled so that a bug will display detailed information in your web browser. It may tell you details about what went wrong, when the problem was encountered and even give file names, function names, and line numbers to help you to track it down. But when you launch your website to the public, it's important to turn off in-browser error reporting. The public should never see such detailed information. Instead, return standard generic error messages. The two most common are 404 and 500 errors. A 404 error says that a page or something else being requested was not found. A 500 error is a general error. It just indicates that something went wrong. You don't need to elaborate. Hackers benefit from the details about errors, but regular users don't. You can provide links back to the main website so that users can recover and continue browsing. Errors can happen with the web server or with the web application. Web servers have their own generic pages to use by default, and they're not very attractive. You can configure both the web server and your web application to use the same standard error pages. That way if something goes wrong at the web server level before a request even gets to your web application, the error page will look the same. It can be a branded page that gives your site a tailored look while also not providing unnecessary information.