Vai al contenuto

File core di WordPress generano errori quando vengono aperti direttamente

Avviso Intero dominio Sicurezza

Istruzioni generali. Apri questo articolo dal tuo report PageCheck per vederlo compilato con l’indirizzo del tuo sito e le regole per il suo server web.

Che cos’è

Alcuni file core di WordPress, come wp-settings.php e i file in wp-includes/, sono pensati per essere caricati solo da WordPress stesso. Aperti direttamente in un browser, vengono eseguiti e si interrompono con un errore PHP.

Cosa non va

Ogni volta che uno di questi file core viene aperto, genera un errore. Se la visualizzazione degli errori è attiva, l’errore compare anche sulla pagina con il percorso completo della cartella del sito sul server, e dice agli aggressori com’è organizzato il server.

Perché va corretto: chiunque – bot o qualcuno con cattive intenzioni – può aprire questi file più e più volte. Ogni richiesta avvia PHP e scrive un altro errore nel log del server, quindi i log possono essere gonfiati di proposito: riempiono il disco e nascondono gli errori che contano. Ogni risposta conferma inoltre che il sito usa WordPress.

Come correggere

1. Nascondi gli errori PHP sul sito online. Gli errori devono finire in un log privato, mai sulla pagina. Nel pannello dell’hosting, imposta display_errors su Off:

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

In wp-config.php tieni attivo il debug, ma invia ogni errore solo a un file di log fuori dalla cartella pubblica del sito, così nulla arriva sulla pagina e nessuno può scaricare il log:

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

Queste righe non coprono i file che questo controllo apre: aperti direttamente, si fermano prima che WordPress legga wp-config.php, quindi è l’impostazione dell’hosting qui sopra a nasconderne gli errori. Ruota il log (ad esempio ogni giorno, conservando qualche settimana): con il debug attivo raccoglie anche gli avvisi e può crescere in fretta.

2. Chiudi i file core di WordPress alle richieste dirette. Usa le regole per il tuo server web (il tuo hosting può dirti quale è):

Apache o LiteSpeed: nel file .htaccess nella cartella principale del sito, sopra la riga «# 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: nel blocco server del sito, sopra il blocco che gestisce i file .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; }

Sono le regole della guida alla protezione di WordPress.org, con una modifica: lasciano aperto wp-includes/ms-files.php. Le reti WordPress Multisite create prima di WordPress 3.5 servono i file caricati tramite quell’unico file, e il consiglio della guida per Multisite – omettere l’intera riga per wp-includes/*.php – riaprirebbe tutti gli altri file in quella cartella. Su un sito singolo il file risponde solo «Multisite support not enabled». Se WordPress è in una sottocartella, inserisci quella cartella in RewriteBase e nei percorsi nginx.

3. Verifica. Apri https://example.com/wp-includes/theme-compat/embed.php: ora dovrebbe rispondere «Forbidden» (403) senza testo di errore. Apri alcune pagine del sito e l’area di amministrazione per vedere che funzionano ancora, poi esegui di nuovo questo controllo. 

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

Controlla il tuo sito per sapere se ha questo problema. Controlla un sito