Today the Giro d’Italia is coming through our province (Utrecht). For this, a special website was set up which gives information on the route and all kinds of related topics. I wanted to check on the info, but instead of getting the main site, I got this:

Now, with sites like this you never know what kind of loads you can get. There are solutions for that (cloud computing would apply well here) but that’s not what I wanted to talk about. I wanted to talk about what I’m seeing in the above image…

Your average visitor will come to your site expecting information. If something goes wrong (which can always happen), they only need to know that something went wrong, and perhaps they should get a phone number or e-mailaddress where they can report the error. At the least, the visitor should be informed of the error in the design of the rest of the website, so that they are aware of the fact that this error is indeed generated by your website, and it’s not a problem on their side for instance.

The thing is, most people won’t know what MySQL is, or which database is giving an error here. For all they know, a database could be part of the browser, and MySQL could be some kind of code for the error.  It gets worse when with some applications full exception stack traces are outputted, sometimes including database credentials. Not only do you give the average visitor information they don’t need, you also give malicious users a huge amount of information they can use to try and get into your application.

If you are working on a website or an application, you should output all that information in your development environment. But before moving to production, this should be switched to a simpler, more user-friendly error-page. Now frameworks such as Zend Framework and symfony have special settings for that using different environments, which makes it really easy for a developer to switch between the developer-view of an error-page and the user-friendly one. Perhaps more systems, including CMS-es, should pay more attention to this. But in the end, it is also the responsibility of the developer to keep this in mind. Next time, before you deploy a new version of your application, consider the error page, and think about what it should and should not expose to your average visitor.

Update: It’s not just your application that you need to check, and so I found out the hard way right after publishing this article and running into some Nginx error 500 pages. I’m going to read up on Nginx configuration soon 😉