WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 3 months ago

#52652 new enhancement

Check for display_errors in Site Health

Reported by: zodiac1978 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Site Health Keywords: needs-codex
Focuses: Cc:

Description

It would be great if we can also check if display_errors is enabled on the server as this is not recommended:
https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#why-are-there-path-disclosures-when-directly-loading-certain-files

Unfortunately there are many hoster (Siteground, 1and1/Ionos, Domainfactory, all-inkl.com, ...) with this setting enabled as default.

There are snippets flying around to add this to the .htaccess, but there are not working in any environment:

<IfModule mod_php7.c> php_flag display_errors off </IfModule>

This is because if PHP is not running as a module but as FastCGI/PHP-FPM you need to use a .user.ini file with the content display_errors = 0 instead or change this in your hoster settings.

First reported here: https://github.com/WordPress/health-check/issues/370

Change History (8)

#1 follow-up: @Clorith
4 months ago

Would it make sense to include this in the existing check that sees if debug log printing is enabled? It's essentially the same, only enabled at the server level, and not through WP_DEBUG, but the outcome is the same.

#2 in reply to: ↑ 1 @zodiac1978
4 months ago

Replying to Clorith:

Would it make sense to include this in the existing check that sees if debug log printing is enabled? It's essentially the same, only enabled at the server level, and not through WP_DEBUG, but the outcome is the same.

In both cases there is a full path disclosure which is possibly revealing private information like usernames/client IDs/etc. - so yes, this could be added to the already existing check IMO.

But we should add some hint, so that a user knows which problem needs fixing. In my case I have already added the mentioned code in the .htaccess and was lost for some hours, until I found the explanation and added the code in a .user.uni.

#3 @Clorith
3 months ago

I think linking to a dotorg document on what this means and the various ways it can be enabled/disabled etc is the best path forward here, since the implementation on host systems can vary, trying to hint at in inside a result may end up being more confusing than helpful I think.

Do we have any documentation on this already that can be linked to? (cc @atachibana as the wizard of HelpHub knowledge)

#4 follow-up: @atachibana
3 months ago

@Clorith

We can see some 'display_errors' at
Configure Error Logging section in Editing wp-config.php:
https://wordpress.org/support/article/editing-wp-config-php/
(Though a bit narrative for non-native English speaker...)

Or, you may use
Hardening WordPress:
https://wordpress.org/support/article/hardening-wordpress/
(Again, a bit narrative...)

#5 in reply to: ↑ 4 @zodiac1978
3 months ago

Thanks for looking up those pages @atachibana

Replying to atachibana:

We can see some 'display_errors' at
Configure Error Logging section in Editing wp-config.php:
https://wordpress.org/support/article/editing-wp-config-php/
(Though a bit narrative for non-native English speaker...)

I am not sure if the examples will work in every case. If it would be necessary to use a .user.ini file it would be not the correct location I think.

Or, you may use
Hardening WordPress:
https://wordpress.org/support/article/hardening-wordpress/
(Again, a bit narrative...)

This looks like the best place to me. It is a full path disclosure and therefore a hardening for WordPress. A new paragraph explaining the issue and possible fixes would be the best way to solve this IMHO.

In Site Health we could link to the new paragraph and if useful to the first article too (because it is explaining the WP constants).

Last edited 3 months ago by zodiac1978 (previous) (diff)

#6 follow-up: @Clorith
3 months ago

  • Keywords needs-codex added
  • Milestone changed from Awaiting Review to Future Release

Sounds like a great approach then, so let's include it as part of the is_in_debug_mode test, and include a link to that new documentation area once it's been written. Adding the needs-codex keyword here, that it is dependent on user-facing documentation being in place before this can be implemented.

#7 in reply to: ↑ 6 @zodiac1978
3 months ago

Replying to Clorith:

Sounds like a great approach then, so let's include it as part of the is_in_debug_mode test, and include a link to that new documentation area once it's been written. Adding the needs-codex keyword here, that it is dependent on user-facing documentation being in place before this can be implemented.

I am not sure how to start a suggestion for this text. On https://make.wordpress.org/docs/handbook/helphub/migrating-articles/ I doesn't found any info about adding content to a page. Can someone point me in the right way? Maybe @atachibana ?

Would it be useful to start with a Google doc?

#8 @atachibana
3 months ago

@zodiac1978

We are trying to use github issues (https://github.com/WordPress/HelpHub/issues) or this ticket system or Slack. (But, in reality, each editor is updating the contents especially when issue was found...)
For this issue, please use this thread so that everyone can watch the same page.

By the way, I'll update your specified handbook page to guide github page for the issue report. Thank you.

Note: See TracTickets for help on using tickets.