WordPress giving too much info to end users on DB error

[AKTed]

My host recently had a short MySQL outage and the apparently stock error page that was shown to everyone visiting my site during this minor hiccup shows way too much information to them!

It shows my full, private database host - something that should only be known to myself, those I explicitly choose to tell, and my host. It also shows - twice - my full, private, shared-hosting path to wp-db.php. This is also something that should be known only to myself, those I explicitly choose to tell, and my host.

[markoheijnen]

The PHP error is that you either have WP_DEBUG on true or server configuration. Showing the database host is something that would always be showed. That is maybe something we should hide.

[AKTed]

@markoheijnen: I do have WP_DEBUG set to true (it's on my live testing/staging site). So, you're saying if it were false, it would show something different to end users? I also was logged into admin at the time, but the error was shown front-end.

[markoheijnen]

You shouldn't use WP_Debug set to true on a live server. Then this is warning is probably not the only one. It shows all notices and warnings.

The message still is the same. You can see that in wp-includes/wp-db.php and search on the error text. Also WordPress doesn't know you are logged in when it can't access the database ;)

[AKTed]

While it is live, as I mentioned it is for testing/staging, so it is accessible to public. I need the notices and warnings. Since I'm not savvy enough to configure my local XAMPP identical to my shared host I use a live testbed.

But if it shows the same errors to end users, regardless of WP_DEBUG setting, then it seems to be a major security issue. No one (other than myself, those I choose, and my host) should have any way to know my site's underlying file structure and DB host.

Since this is on my shared hosting account, my "for real" live site and my testbed use the same DB servers. They do have their own DB's, though. I imagine (but didn't have time to test) that when my testbed was down, my live site was down as well.

[dd32]

There is a slight difference in how the dead db message is handled, on front-end and back-end:

For example, This is what a user on a production server will see when http://example.com/wp-admin/ is accessed: ​http://cl.ly/image/342a2C3a3c2L or ​http://cl.ly/image/1E3B0i1Y1b19 depending on the actual connection issue

On the other hand, Visitors to http://example.com/ and http://example.com/some-post-name/ will get a much more bland page like this: ​http://cl.ly/image/2j371N2R0v1p

The first message exposes the database name OR database server name (usually localhost). Neither of these pieces of information should be critical to security, but they're invaluable to users who don't understand why their site isn't working..

[AKTed]

@dd32: Thanks for the response. The error page shown in my ticket is what was presented front-end. I wouldn't have an issue back-end.

The problem stemmed from a temporary outage of my host's DB server. While that is something I can't control, I do want to control what an end-user sees. It's akin to a credit card number. It isn't critical to keep that number plus the associated name out of the world's hands, but you don't advertise the number on your business card.

[SergeyBiryukov]

Replying to AKTed:

I do have WP_DEBUG set to true (it's on my live testing/staging site). So, you're saying if it were false, it would show something different to end users?

Yes. It would show "Error establishing a database connection", as in ​http://cl.ly/image/2j371N2R0v1p.

wpdb class only shows detailed errors on front-end if WP_DEBUG is true:
​http://core.trac.wordpress.org/browser/tags/3.5/wp-includes/wp-db.php#L539

[AKTed]

Thank you for the clarification, Sergey. I feel much better now. When @markoheijnen said "The message still is the same" in response to my question about WP_DEBUG affecting the end-user message, I misinterpreted that to mean that the user will see the same error, including private information, regardless of WP_DEBUG setting.

I can sleep easy now. :)