Sicurezza delle cartelle WordPress: bloccare l’accesso ai PHP in wp-includes

Sicurezza struttura cartelle WordPress: il modo più efficace per proteggere il sito è bloccare l'esecuzione dei file PHP nella cartella "wp-includes" e disabilitare l’indicizzazione delle directory, senza impedire l’accesso totale. Questo perché wp-includes contiene JavaScript, CSS e file statici necessari al core di WordPress; chiudere completamente la cartella può causare malfunzionamenti nel design, nell’editor o nei plugin. L’approccio corretto: se usi Apache, imposta regole .htaccess; se usi Nginx, configura una regola location. Verifica poi con risposte 403/404 e test delle pagine critiche.

Uno degli errori più comuni nella sicurezza WordPress è affidarsi solo a password forti o a plugin di sicurezza. Gli attaccanti spesso scandagliano cartelle core, plugin obsoleti, permessi errati e directory aperte. wp-includes è tra i bersagli preferiti. In questa guida scopri come restringere l’accesso a wp-includes in ambienti reali di hosting, quali regole possono causare problemi, esempi per Apache e Nginx, metodi di test e checklist di manutenzione. Per una protezione completa valuta anche Hosting WordPress e per la sicurezza generale certificato SSL.

Cosa è la cartella wp-includes e perché va protetta?

wp-includes è una delle cartelle centrali che ospita le librerie base del core WordPress. Qui risiedono il sistema dei temi, il bloc editor, i componenti REST API, la gestione media, classi, funzioni e script JavaScript. In breve: wp-includes è il “motore” del sito, non una directory che gli utenti devono visitare direttamente.

Un visitatore normale non dovrebbe mai aprire site.com/wp-includes/. Tuttavia, nel codice sorgente possono apparire asset statici da questa cartella, come script di default, emoji, o elementi dell’editor. La protezione quindi deve essere mirata: bloccare l’esecuzione dei PHP via web, lasciando accessibili i file statici.

Questa distinzione è la base di una strategia di Sicurezza struttura cartelle WordPress professionale. Bloccare le cartelle a caso sembra sicuro, ma può causare errori gravi: pagina bianca, admin rotto, editor bloccato o temi sfigurati. L’obiettivo: ridurre la superficie di attacco proteggendo i file necessari al funzionamento.

Quali vantaggi dà bloccare l’accesso a wp-includes?

Bloccare l’esecuzione diretta dei PHP in wp-includes non ferma tutti gli attacchi, ma riduce molto la superficie di rischio. In particolare, se il sito è stato infettato, gli hacker cercano di caricare o richiamare file PHP nelle cartelle accessibili. Impedire l’esecuzione PHP in wp-includes crea una barriera extra.

Questo accorgimento offre:

• Limita le chiamate dirette ai file PHP core via URL.
• Se l’indicizzazione directory è attiva, aiuta a nascondere i contenuti sensibili.
• Riduce la perdita di informazioni verso bot automatici.
• Protegge anche senza plugin, agendo a livello server.
• Rafforza la sicurezza a più livelli con WAF, SSL, permessi e PHP aggiornato.

Importante: questa è una protezione a strati. Se hai plugin obsoleti, password deboli o FTP compromesso, la regola wp-includes non basta. La sicurezza dipende da hosting, applicazione, gestione utenti e manutenzione regolare. Per una base sicura vedi Hosting Web Sicuro e per la gestione dominio Sicurezza del dominio.

Errori comuni nel bloccare wp-includes

Bloccare tutta la cartella

Errore tipico: bloccare ogni richiesta HTTP a wp-includes con un 403. Sembra sensato, ma WordPress carica asset statici da questa directory e ciò può causare problemi: editor bloccato, JavaScript mancanti, temi rovinati.

Non testare la regola prima di andare online

Un errore anche minimo in .htaccess o nella configurazione Nginx può causare un 500 Internal Server Error. In siti ad alto traffico è rischioso applicare subito la regola. Prima fai backup, testa su staging e poi applica gradualmente. Se usi Hostragons e staging/back-up, inserisci Backup Web Hosting come collegamento interno.

Affidarsi solo ai plugin di sicurezza

I plugin sono utili, ma le regole server agiscono prima. Se una richiesta viene bloccata da Apache/Nginx prima di arrivare a PHP, il consumo di risorse è minore. Quindi anche con plugin, non trascurare le regole di base lato server.

Checklist prima di applicare la protezione

Prepararsi riduce molto il rischio di interruzioni. Usa questa checklist prima di restringere l’accesso a wp-includes, soprattutto su siti live:

• Fai backup del file .htaccess o della configurazione Nginx.
• Aggiorna core WordPress, temi e plugin.
• Controlla che la versione PHP sia supportata e sicura.
• Verifica i permessi: cartelle di solito 755, file 644.
• Non lasciare scrittura inutile su wp-config.php e .htaccess.
• Se usi cache, CDN o plugin di sicurezza, pianifica la pulizia dopo le modifiche.
• Crea una lista di pagine critiche da testare: admin, homepage, articoli, form contatti, pagine pagamento.

Questa preparazione richiede 10-15 minuti, ma evita ore di downtime. Nei siti aziendali, applica le regole in orari di basso traffico.

Bloccare i PHP in wp-includes con .htaccess su Apache

Nel hosting Apache la soluzione più comune è il file .htaccess. Le regole giuste bloccano le chiamate ai PHP in wp-includes senza impedire l’accesso agli asset statici. Prima di modificare, scarica una copia del file o crea un backup dal pannello hosting.

Regola consigliata per .htaccess

Questa regola blocca solo l’esecuzione PHP in wp-includes, lasciando intatti i file statici:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

Funziona così: se l’URL inizia con wp-includes e finisce con .php, la richiesta viene negata. Così i PHP non sono eseguibili via browser, ma JS, CSS, PNG e SVG restano accessibili. È il compromesso ideale per frontend e admin.

Disabilitare l’indicizzazione delle directory

Altra impostazione importante: disabilitare l’indicizzazione. Se attiva, è possibile vedere l'elenco dei file delle cartelle. Nel tuo .htaccess aggiungi:

Options -Indexes

Questo impedisce la visualizzazione dei file dove manca un index. Di solito è disattivato di default, ma controllare è buona prassi.

Test dopo la modifica

Dopo aver aggiunto la regola:

• Apri site.com/wp-includes/ – non deve mostrarsi la directory.
• Prova a richiamare un file PHP noto in wp-includes – la risposta deve essere 403 o 404.
• Controlla homepage, articoli e admin.
• Nel browser, usa gli strumenti Console e Network per verificare errori 403/404.
• Pulisci la cache se usi plugin o CDN.

Se tutto funziona, lascia la regola in produzione. Se compare un errore 500, rimuovi subito le righe aggiunte o ripristina il file di backup.

Bloccare i PHP in wp-includes su Nginx

Con Nginx (.htaccess non funziona), la regola va inserita nel file di configurazione del sito, dentro il blocco server. Serve accesso SSH e permessi di modifica. Se non sei sicuro, chiedi supporto al tuo hosting.

Regola consigliata Nginx location

La logica è questa:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

Questa regola blocca tutte le richieste PHP nella cartella wp-includes. Dopo aver modificato, testa la configurazione:

nginx -t

Se tutto è ok, ricarica Nginx:

systemctl reload nginx

Il reload è più sicuro del restart: aggiorna la configurazione senza interrompere le connessioni attive. Esegui le modifiche in orari di basso traffico.

Accortezze con Nginx

• Inserisci la regola nel blocco server giusto: potresti avere più siti sullo stesso server.
• Se usi CDN o reverse proxy, testa dopo aver svuotato la cache.
• Assicurati che PHP-FPM processi solo i file necessari.
• Controlla log: access.log ed error.log mostrano eventuali errori.

Un errore nel posizionamento delle regole location può causare risultati imprevisti. Verifica che non ci siano conflitti con permalink WordPress o altri blocchi PHP.

Confronto tra i metodi

La tabella seguente riassume i principali metodi per limitare l’accesso a wp-includes:

La soluzione migliore è usare i metodi insieme: ad esempio, su Apache regola .htaccess, permessi giusti, core aggiornato, SSL e backup. Firewall e isolamento hosting sono cruciali, quindi Hosting Aziendale è importante per siti critici.

Permessi e proprietà dei file

Bloccare wp-includes serve a poco se i permessi sono errati. I valori standard WordPress: cartelle 755, file 644. Questi permettono al server di leggere ma non modificare i file senza motivo. In alcuni hosting possono esserci differenze, segui le raccomandazioni del tuo pannello.

Il permesso 777 è un rischio grave: chiunque può scrivere nella cartella, facilitando upload malevoli. Anche in wp-content/uploads, dove serve scrittura, va impedita l’esecuzione PHP. wp-includes non deve essere scrivibile, salvo aggiornamenti WordPress.

Durante un controllo di sicurezza verifica:

• wp-includes: di solito 755
• PHP in wp-includes: di solito 644
• wp-config.php: preferibilmente 600 o più restrittivo
• .htaccess: di solito 644, senza scrittura inutile

Questi valori possono variare. Permessi sbagliati impediscono aggiornamenti o lettura file. Dopo modifiche, controlla la salute WordPress e i log errori.

I plugin di sicurezza bloccano wp-includes?

Plugin come Wordfence o iThemes Security propongono regole di hardening automatiche. Sono utili per protezione brute force, monitoraggio file, scansioni malware e login. Tuttavia, verifica cosa fanno sulla cartella wp-includes.

Alcuni plugin aggiungono regole .htaccess, altri proteggono solo a livello applicativo. La protezione applicativa interviene dopo che la richiesta arriva a WordPress, mentre il blocco server è più tempestivo. L’approccio professionale è combinare plugin e regole server.

Se usi plugin di sicurezza, controlla:

• Se aggiunge regole .htaccess o Nginx.
• Che non ci siano conflitti tra regole simili.
• Che i settaggi restino dopo l’aggiornamento del plugin.
• Monitora cache e risorse server per valutare l’impatto.

Evita di usare più plugin di sicurezza contemporaneamente: firewall e regole login/rewrite in conflitto possono rallentare il sito o bloccare accessi legittimi.

Test pratico della protezione wp-includes

Non basta vedere il sito online: usa questo test in 7 passaggi, valido per blog e ecommerce:

• 1. Apri la homepage in una sessione anonima e controlla eventuali problemi visivi.
• 2. Visita un articolo, una categoria e una pagina di ricerca.
• 3. Accedi all’admin, prova il block editor e la galleria media.
• 4. Verifica la Console del browser per errori.
• 5. Su Network, controlla che gli asset statici in wp-includes non siano bloccati.
• 6. Prova a richiamare un file PHP in wp-includes: devi ricevere 403 o 404.
• 7. Esamina i log server per errori nuovi o ripetuti.

Questo test richiede circa 5 minuti e individua rapidamente configurazioni errate. Su siti WooCommerce, testa anche carrello, checkout e account utente: un errore JavaScript può impattare le conversioni.

Ulteriori accorgimenti per la sicurezza delle cartelle WordPress

La protezione di wp-includes è solo una parte. Ecco altri consigli per ridurre il rischio:

• Non nascondere la versione WordPress, tieni il core sempre aggiornato.
• Elimina completamente temi e plugin inutilizzati.
• Scegli username admin difficili da indovinare.
• Attiva l’autenticazione a due fattori.
• Se non usi XML-RPC, limitane l’accesso.
• Applica rate limit o verifica extra su wp-login.php.
• Testa backup e ripristino ogni giorno.
• Usa HTTPS ovunque: senza SSL i dati login sono a rischio.

L’SSL non blocca direttamente wp-includes, ma protegge sessioni, dati form e admin. Per questo è sempre una priorità nelle guide di sicurezza WordPress. Inserisci acquista certificato SSL e Installazione SSL gratuita come link naturali.

Quando chiedere supporto professionale?

Aggiungere una regola .htaccess su Apache è gestibile dalla maggior parte degli utenti. Ma se hai configurazioni Nginx avanzate, multisite, negozi WooCommerce, siti news ad alto traffico o portali aziendali, meglio rivolgersi a un esperto. Le regole non devono solo essere tecnicamente corrette, ma anche sicure per la continuità aziendale.

Richiedi supporto in questi casi:

• Hai più siti WordPress sullo stesso server.
• Usi Nginx, Varnish, CDN e WAF insieme.
• Dopo modifiche aumentano errori 403, 404 o 500.
• Il sito è stato già infettato da malware.
• Gestisci pagamenti, iscrizioni o dati personali.

Un’infrastruttura hosting sicura, backup regolari e supporto esperto sono fondamentali. Quando scegli, valuta non solo lo spazio disco, ma anche backup, firewall, PHP, SSL e qualità assistenza. Vedi Pacchetti Hosting Hostragons e Trasferimento del sito WordPress per approfondire.

Conclusioni

Nella Sicurezza struttura cartelle WordPress la soluzione migliore non è bloccare tutta wp-includes, ma impedire l’esecuzione diretta dei PHP e disattivare l’indicizzazione dei file. Su Apache usa .htaccess, su Nginx regole location: il tutto applicabile in pochi minuti. Prima di ogni modifica, fai backup e testa admin/frontend.

In sintesi: non bloccare gli asset statici, limita i PHP, disabilita l’indicizzazione, controlla i permessi e aggiorna regolarmente. Per una WordPress più sicura e gestibile, esplora le soluzioni hosting, dominio e SSL di Hostragons e chiedi supporto per una configurazione su misura.

Domande Frequenti

Bloccare completamente wp-includes è sicuro?

No, non è consigliato. wp-includes contiene JS, CSS e file statici essenziali. Bloccare tutto può rovinare il sito o l’admin. Meglio bloccare solo l’accesso diretto ai PHP.

Cosa fare se dopo la regola .htaccess compare errore 500?

Rimuovi subito le righe aggiunte o ripristina il backup .htaccess. Controlla la sintassi della regola. Se persiste, verifica i log errori del hosting o chiedi supporto tecnico.

.htaccess funziona su Nginx?

No. .htaccess è per Apache/LiteSpeed. Su Nginx le restrizioni vanno inserite nelle regole location nel server block, e testate con nginx -t.

Questa protezione rende WordPress completamente sicuro?

No. Bloccare i PHP in wp-includes è un importante livello di sicurezza, ma non basta. Aggiornamenti, password forti, autenticazione a due fattori, SSL, backup e permessi vanno applicati insieme.

Se uso un plugin di sicurezza, devo aggiungere comunque la regola wp-includes?

Dipende dal plugin: alcuni aggiungono regole .htaccess, altri proteggono solo a livello applicativo. In genere, la restrizione server-level è più efficace, senza conflitti.