Why You Shouldn’t Run Production in Debug Mode

Nette Framework is the third most popular PHP framework of 2015, according to SitePoint, and in my opinion, one of the most secure frameworks available.

As a monitoring service, we often gather data and information about our projects to gain insight about ways to improve Testomato. The following post is meant to highlight a recent problem we recently noticed on websites built with Nette.

The Problem

It’s no wonder Nette Framework is a favorite among developers. It gives you a lot of options to make your work easier: Switching PHP applications to development mode, checking for errors and SQL queries, debugging routes, viewing failed PHP code and the values of variables, and more.

It’s possible to do all of the above with the help of the Tracy Debug Bar, which shows up as a floating panel displayed in the bottom right corner of a page. You can move it using your mouse, and it will remember its position.

Here’s what it looks like:

The Debugger Bar automatically detects production, but it’s possible to override this option and instead set: debug on all environments.

And if code accidentally gets uploaded to your server in debug mode? It’s like standing in front of a crowd under a spotlight. You can’t hide your weaknesses, and it makes you vulnerable.

There are several performance reasons, which make debugging code less than helpful on production, but it goes beyond just slowing your website down. I’d like to highlight the possible security risks you run using real-life examples our team recently came across.

What We Found

Testomato checked 6,354 websites made using Nette Framework (mostly from Czech Republic) and found that 37 of them are running production in debug mode.  

Based on those 37 sites, I pulled together a quick list of information that was exposed and vulnerable when debug mode is activated on production. In order to protect the identity of the websites we’ve checked, all URLs and variable values have been hidden.

1) Connection string to database(including password and hostname)

If you username, password, and hostname are exposed, it’s possible for others to access your database.

2) PHP notifications 

Some websites contain small bugs in the PHP code, which generate notifications. While they don’t pose any significant risk to your website, they belong in your server logs and not exposed where anyone can view them.

3) SQL queries

The database extension of the Tracy Debug Bar also shows SQL queries, which are very sensitive. If they are exposed, it could possible leave your database open to an attack.

4) Session, router panels and current identity

Some servers show a session panel, router panel and SQL queries, and current identity. While this is helpful when you’re debugging your site, this can be risky if someone is able to view them in production. Revealing how your website is made could invite a server attack and endanger others if you have shared hosting.

How can Testomato help?

We know mistakes happen. Testomato automatically monitors projects for both Nette’s Tracy Debug Bar and Symfony’s Web Debug Toolbar. If Testomato detects debugging output on your website, we’ll send you an alert immediately.

More questions debugger output detection in Testomato? 

Please leave us a comment here or tweet us @testomatocom.