Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#23140 closed defect (bug) (invalid)

WordPress giving too much info to end users on DB error

Reported by: akted's profile AKTed Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5
Component: Database Keywords:
Focuses: Cc:


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.

Change History (10)

#1 @AKTed
11 years ago

  • Version set to 3.5

#2 @markoheijnen
11 years ago

  • Severity changed from major to normal

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.

#3 follow-up: @AKTed
11 years ago

@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?

Version 0, edited 11 years ago by AKTed (next)

#4 @markoheijnen
11 years ago

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 ;)

#5 @AKTed
11 years ago

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.

#6 @dd32
11 years ago

  • Keywords close added

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 is accessed: or depending on the actual connection issue

On the other hand, Visitors to and will get a much more bland page like this:

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..

#7 @AKTed
11 years ago

@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.

#8 in reply to: ↑ 3 @SergeyBiryukov
11 years ago

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

wpdb class only shows detailed errors on front-end if WP_DEBUG is true:

#9 @AKTed
11 years ago

  • Resolution set to invalid
  • Status changed from new to closed

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. :)

#10 @SergeyBiryukov
11 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.