Aller au contenu

Des fichiers du cœur de WordPress génèrent des erreurs quand on les ouvre directement

Avertissement Tout le domaine Sécurité

Instructions générales. Ouvrez cet article depuis votre rapport PageCheck pour le voir rempli avec l’adresse de votre site et les règles pour son serveur web.

De quoi s’agit-il

Certains fichiers du cœur de WordPress, comme wp-settings.php et les fichiers de wp-includes/, ne sont censés être chargés que par WordPress lui-même. Ouverts directement dans un navigateur, ils s’exécutent et s’arrêtent sur une erreur PHP.

Ce qui ne va pas

Chaque fois qu’un de ces fichiers du cœur est ouvert, il génère une erreur. Si l’affichage des erreurs est activé, l’erreur apparaît aussi sur la page avec le chemin complet du dossier du site sur le serveur, ce qui indique aux attaquants l’organisation du serveur.

Pourquoi il faut le corriger : n’importe qui – des robots ou une personne mal intentionnée – peut ouvrir ces fichiers encore et encore. Chaque requête lance PHP et écrit une erreur de plus dans le journal du serveur : on peut ainsi gonfler les journaux volontairement, ce qui remplit le disque et noie les erreurs importantes. Chaque réponse confirme aussi que le site tourne sous WordPress.

Comment corriger

1. Masquer les erreurs PHP sur le site en ligne. Les erreurs doivent aller dans un journal privé, jamais sur la page. Dans le panneau de l’hébergement, mettez display_errors sur Off :

  • Plesk : Websites & Domains → PHP Settings → display_errors désactivé.
  • cPanel : MultiPHP INI Editor → display_errors Disabled.

Dans wp-config.php, gardez le débogage activé mais envoyez chaque erreur uniquement dans un fichier journal hors du dossier public du site : rien n’apparaît sur la page et personne ne peut télécharger le journal :

wp-config.php

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/path/outside/the/web/root/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

Ces lignes ne couvrent pas les fichiers que ce contrôle ouvre : ouverts directement, ils s’arrêtent avant que WordPress ne lise wp-config.php, c’est donc le réglage de l’hébergement ci-dessus qui masque leurs erreurs. Faites tourner le journal (par exemple chaque jour, en gardant quelques semaines) : avec le débogage activé, il recueille aussi les avertissements et peut vite grossir.

2. Fermer les fichiers du cœur de WordPress aux requêtes directes. Utilisez les règles de votre serveur web (votre hébergeur peut vous dire lequel c’est) :

Apache ou LiteSpeed : dans le fichier .htaccess du dossier principal du site, au-dessus de la ligne « # BEGIN WordPress »

# BEGIN Block WordPress internal files
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/(?!ms-files\.php$)[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
<Files "wp-settings.php">
    Require all denied
</Files>
# END Block WordPress internal files

nginx : dans le bloc server du site, au-dessus du bloc qui traite les fichiers .php

location ~* ^/wp-admin/includes/ { deny all; }
location ~* ^/wp-includes/(?!ms-files\.php$)[^/]+\.php$ { deny all; }
location ~* ^/wp-includes/js/tinymce/langs/.+\.php$ { deny all; }
location ~* ^/wp-includes/theme-compat/ { deny all; }
location = /wp-settings.php { deny all; }

Ce sont les règles du guide de sécurisation de WordPress.org, avec un changement : elles laissent wp-includes/ms-files.php ouvert. Les réseaux WordPress Multisite créés avant WordPress 3.5 servent leurs fichiers téléversés par ce seul fichier, et le conseil du guide pour Multisite – omettre toute la ligne pour wp-includes/*.php – rouvrirait tous les autres fichiers de ce dossier. Sur un site simple, le fichier répond seulement « Multisite support not enabled ». Si WordPress est dans un sous-dossier, mettez ce dossier dans RewriteBase et dans les chemins nginx.

3. Vérifier. Ouvrez https://example.com/wp-includes/theme-compat/embed.php : l’adresse doit maintenant répondre « Forbidden » (403), sans texte d’erreur. Ouvrez quelques pages du site et l’administration pour voir qu’elles fonctionnent toujours, puis relancez ce contrôle. 

Stop WordPress's core PHP files on my site from running and generating errors when opened directly.
Why it matters: anyone (bots included) can request these core files repeatedly, and every request writes a PHP error to the server log, so the logs can be bloated on purpose.

Steps:
1. Turn display_errors off for the live site (hosting PHP settings or php.ini). In wp-config.php keep WP_DEBUG true, set WP_DEBUG_DISPLAY false, and point WP_DEBUG_LOG to a file outside the web root (not wp-content/debug.log), with log rotation. Do not set WP_DEBUG to false.
2. Deny direct HTTP requests to wp-admin/includes/, wp-includes/*.php, wp-includes/js/tinymce/langs/*.php, wp-includes/theme-compat/ and wp-settings.php — WordPress.org's hardening rules in .htaccess on Apache/LiteSpeed (above # BEGIN WordPress), or deny location blocks placed before the PHP handler on nginx. Exempt only wp-includes/ms-files.php (Multisite networks from before WordPress 3.5 serve uploads through it): use ^wp-includes/(?!ms-files\.php$)[^/]+\.php$ rather than dropping the wp-includes/*.php rule.
3. Verify those addresses answer 403 with no error text, and that the site, the admin area, the block editor and uploads still work.
Tell me exactly which files you changed.

Resources:
- Hardening WordPress, securing wp-includes (WordPress.org): https://developer.wordpress.org/advanced-administration/security/hardening/#securing-wp-includes
- Debugging in WordPress (WordPress.org): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
- display_errors (PHP manual): https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

Analysez votre site pour savoir s’il a ce problème. Analyser un site