Sécuriser la structure des dossiers WordPress : Bloquer l'accès aux fichiers PHP du dossier "wp-includes"

Sécurité de la structure des dossiers WordPress : pour protéger efficacement votre site, il est essentiel de bloquer l’exécution des fichiers PHP dans le dossier wp-includes sans pour autant empêcher l’accès aux fichiers statiques (JavaScript, CSS, images) nécessaires au bon fonctionnement du CMS. En effet, wp-includes contient le cœur des librairies WordPress, des scripts, des styles, mais aussi des fichiers indispensables à l’éditeur et aux extensions. Si vous bloquez l’accès à tout le dossier de manière aveugle, vous risquez de casser l’affichage du site ou l’administration. L’approche recommandée : pour Apache, créez une règle .htaccess ; pour Nginx, insérez une règle location dans le server block pour limiter l’exécution des fichiers PHP. Enfin, vérifiez le résultat via les codes 403/404 et testez les pages critiques de votre site.

L’une des erreurs les plus fréquentes en matière de sécurité WordPress est de se contenter d’un mot de passe fort ou d’une extension de sécurité. Or, les pirates ciblent souvent les dossiers du noyau, les plugins obsolètes, les droits d’accès mal configurés et la liste des fichiers accessibles publiquement. wp-includes est régulièrement visé par des scans automatisés. Ce guide vous donne une méthode applicable sur tout hébergement pour restreindre l’accès à wp-includes, éviter les erreurs courantes, configurer Apache et Nginx, tester la mise en place et maintenir la sécurité. Pour un site WordPress vraiment robuste, pensez aussi à Hébergement WordPress et à une protection globale via certificat SSL.

Qu’est-ce que le dossier wp-includes et pourquoi le protéger ?

wp-includes est l’un des dossiers centraux du noyau WordPress. Il héberge les librairies PHP principales, le système de thème, l’éditeur de blocs, l’API REST, la gestion des médias, des classes, des fonctions et de nombreux fichiers JavaScript. En résumé, c’est la salle des machines de WordPress : les visiteurs n’ont jamais à consulter ce dossier directement.

Un internaute n’a aucune raison d’accéder à site.com/wp-includes/, mais on retrouve souvent dans le code source des pages des assets qui proviennent de ce dossier (scripts par défaut, emoji, composants d’éditeur, etc.). La sécurité doit donc cibler l’exécution des fichiers PHP, sans perturber la livraison des fichiers statiques.

Cette nuance est au cœur d’une approche professionnelle de la sécurité des dossiers WordPress. Bloquer un dossier au hasard peut sembler efficace, mais provoque souvent des pages blanches, un back-office inaccessible, un éditeur bloqué ou des thèmes cassés. Le but est de réduire la surface d’attaque en protégeant uniquement les fichiers sensibles.

Quels bénéfices à bloquer l’exécution PHP dans wp-includes ?

Empêcher l’exécution directe de fichiers PHP dans wp-includes ne protège pas contre toutes les attaques, mais réduit considérablement les risques. Sur un site compromis, un pirate cherchera souvent à déposer ou à exécuter un fichier PHP là où il est accessible. Bloquer l’accès direct aux scripts PHP de wp-includes crée une barrière supplémentaire.

Voici ce que vous gagnez :

• Les fichiers PHP du noyau ne peuvent plus être appelés par URL directe.
• Si l’indexation des dossiers est active, cela limite la visibilité de leur contenu.
• Diminue la fuite d’informations lors de scans automatisés.
• Offre une protection serveur, même sans plugin de sécurité.
• Renforce la sécurité globale en association avec WAF, SSL, PHP à jour et droits d’accès corrects.

Attention toutefois : cette règle n’est qu’une couche de sécurité. Si vos plugins ne sont pas à jour, vos mots de passe sont faibles ou votre FTP est compromis, la restriction sur wp-includes ne suffira pas. La sécurité combine hébergement, application, gestion des utilisateurs et maintenance régulière. Pour une base solide, consultez Hébergement Web Sécurisé et pour la protection du nom de domaine Sécurité du domaine.

Erreurs courantes lors de la restriction de wp-includes

Bloquer tout le dossier

L’erreur la plus répandue consiste à interdire tous les accès HTTP au dossier wp-includes (code 403). À première vue, c’est logique, mais WordPress charge des fichiers statiques depuis ce dossier. Vous pourriez alors casser l’éditeur de blocs, empêcher le chargement de scripts JS ou provoquer des défauts visuels critiques.

Appliquer la règle sans test

Une erreur dans le .htaccess ou la configuration Nginx peut générer un 500 Internal Server Error. Sur un site à fort trafic, déployer sans test est très risqué. Sauvegardez d’abord le fichier, testez sur une version de staging si possible, puis appliquez sur la version live avec prudence. Si votre hébergeur propose des outils de staging ou de sauvegarde, Sauvegarde d'hébergement Web est une ressource utile.

Se fier uniquement au plugin de sécurité

Les plugins sont utiles, mais les règles au niveau du serveur interviennent avant même que WordPress soit sollicité, ce qui réduit la consommation de ressources. Même avec un plugin, ne négligez pas les règles serveur.

Checklist avant de restreindre wp-includes

Avant toute modification, une courte préparation permet d’éviter les interruptions. Voici la checklist recommandée pour tout site WordPress en production :

• Sauvegardez le fichier .htaccess ou la configuration Nginx existante.
• Mettez à jour le noyau WordPress, les thèmes et les plugins.
• Vérifiez que votre version de PHP est supportée et sécurisée.
• Contrôlez les droits d’accès : dossiers en 755, fichiers en 644.
• Évitez de laisser en écriture wp-config.php et .htaccess inutilement.
• Pensez à vider le cache si vous utilisez un plugin, CDN ou extension de sécurité.
• Préparez une liste de pages critiques à tester : admin, accueil, article, formulaire, paiement.

Cette préparation prend environ 10-15 minutes, mais vous évite des heures de panne en cas d’erreur. Sur un site professionnel, intervenez de préférence en heures creuses.

Bloquer l’exécution PHP dans wp-includes sous Apache (.htaccess)

Sur un hébergement mutualisé Apache, le moyen le plus simple est d’ajouter une règle dans le fichier .htaccess du dossier principal WordPress. Avant toute modification, téléchargez ou sauvegardez le fichier sur votre ordinateur ou via le gestionnaire de fichiers du panel de votre hébergeur.

Règle .htaccess recommandée

Le snippet suivant bloque l’exécution des fichiers PHP dans wp-includes sans empêcher les fichiers statiques :

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

Le principe : toute URL commençant par wp-includes et finissant par .php est interdite. Les fichiers JS, CSS, PNG, SVG restent accessibles, préservant l’affichage du site et l’admin.

Désactiver la liste des fichiers du dossier

Autre réglage crucial : empêcher l’indexation des dossiers. Ajoutez dans votre .htaccess principal :

Options -Indexes

Cette ligne empêche l’affichage de la liste des fichiers si aucun index n’est présent. Elle est souvent activée par défaut sur les hébergeurs modernes, mais vérifiez tout de même.

Tests après modification

Après ajout de la règle :

• Ouvrez votre-site.com/wp-includes/ : la liste des fichiers ne doit pas s’afficher.
• Tentez d’appeler un fichier PHP connu dans wp-includes : vous devez obtenir un 403 ou 404.
• Vérifiez l’accueil, les articles, l’admin.
• Dans les outils développeur du navigateur, regardez les erreurs 403/404 dans Console et Network.
• Videz le cache des plugins ou du CDN.

Si ces tests sont concluants, la règle est opérationnelle en production. Si vous obtenez un code 500, retirez les lignes ajoutées ou restaurez le .htaccess de sauvegarde.

Bloquer l’exécution PHP dans wp-includes sous Nginx

Sur un VPS, serveur dédié ou hébergement managé Nginx, le .htaccess n’est pas utilisable. Il faut ajouter une règle dans le fichier de configuration du serveur (server block), ce qui nécessite un accès SSH et des droits de modification. En cas de doute, demandez l’aide du support technique de votre hébergeur.

Règle location Nginx recommandée

Le snippet suivant bloque l’exécution des fichiers PHP dans wp-includes :

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

Après ajout, testez la configuration :

nginx -t

Si le test est OK, rechargez Nginx :

systemctl reload nginx

La commande reload est moins brutale que restart, elle évite de couper les connexions actives. Sur un site sensible, appliquez la règle en heure creuse.

Points d’attention sous Nginx

• Assurez-vous d’ajouter la règle au bon server block (plusieurs sites sur un même serveur).
• Si vous utilisez un CDN ou un reverse proxy, videz leur cache avant de tester.
• Vérifiez que PHP-FPM n’accepte que les fichiers nécessaires.
• Consultez les logs access.log et error.log pour repérer d’éventuelles erreurs.

Un ordre incorrect des règles location peut provoquer des résultats inattendus. Vérifiez qu’il n’y a pas de conflits avec les règles de permaliens ou d’exécution PHP.

Comparatif des méthodes

Le tableau suivant résume les principales méthodes pour restreindre l’accès à wp-includes :

Le meilleur résultat est obtenu en combinant ces méthodes : .htaccess pour Apache, droits d’accès corrects, WordPress à jour, SSL et sauvegarde régulière forment une défense en profondeur. Pour les sites critiques, le choix d’un hébergement sécurisé et isolé (Hébergement Professionnel) fait la différence.

Droits d’accès et propriété des fichiers

Restreindre wp-includes n’a d’intérêt que si les droits d’accès sont corrects. La norme WordPress : dossiers en 755, fichiers en 644. Ceci permet au serveur de lire les fichiers sans risque d’écriture non autorisée. Certains hébergeurs utilisent des configurations particulières ; suivez leurs recommandations.

La permission 777 représente un risque majeur : tout le monde peut écrire dans le dossier, ce qui facilite les attaques. Même sur wp-content/uploads (qui doit être écrivable), pensez à bloquer l’exécution PHP. wp-includes ne devrait jamais être modifiable par l’utilisateur en dehors des mises à jour WordPress.

À contrôler lors d’un audit :

• Dossier wp-includes : 755
• Fichiers PHP de wp-includes : 644
• wp-config.php : 600 si possible, ou plus restrictif selon votre hébergeur
• .htaccess : 644, sans écriture superflue après modification

Ces réglages peuvent varier selon l’hébergeur. Une permission incorrecte peut empêcher les mises à jour ou la lecture des fichiers. Après modification, vérifiez la santé du site WordPress et les logs d’erreur.

Les plugins de sécurité gèrent-ils cette protection ?

Des extensions comme Wordfence ou iThemes Security proposent parfois des règles de renforcement automatique. Elles protègent contre le brute force, surveillent les changements de fichiers, détectent les malwares et sécurisent la connexion. Mais pour le blocage de wp-includes, vérifiez explicitement ce que fait votre plugin.

Certains plugins ajoutent la règle dans le .htaccess, d’autres n’agissent que côté application. Or, la protection au niveau application intervient après que la requête ait atteint WordPress, donc moins tôt que la restriction serveur. L’approche professionnelle : combiner plugin et règles serveur.

Si vous utilisez un plugin de sécurité, vérifiez :

• Si le plugin ajoute une règle .htaccess ou Nginx pour wp-includes.
• Qu’il n’y a pas de conflit entre plusieurs règles similaires.
• Que les réglages ne sont pas modifiés lors d’une mise à jour du plugin.
• Que la performance est préservée (cache et ressources serveur).

Évitez de cumuler plusieurs plugins de sécurité : firewall, login et rewrite rules en conflit nuisent à la performance et peuvent bloquer des utilisateurs légitimes.

Tester la protection wp-includes : scénario pratique

Pour vérifier que la protection fonctionne, ne vous contentez pas d’ouvrir le site. Voici un test en 7 étapes applicable aussi bien sur un site vitrine que sur un projet e-commerce :

• 1. Ouvrez la page d’accueil en navigation privée, vérifiez l’affichage.
• 2. Visitez un article, une catégorie et une page de résultats de recherche.
• 3. Accédez à l’admin, ouvrez l’éditeur de blocs et la médiathèque.
• 4. Vérifiez la console développeur du navigateur.
• 5. Dans Network, assurez-vous que les fichiers statiques de wp-includes ne sont pas bloqués.
• 6. Appelez directement un fichier PHP de wp-includes : vous devez obtenir une erreur 403 ou 404.
• 7. Consultez les logs serveur pour détecter toute erreur nouvelle ou répétée.

Ce test prend 5 minutes et permet de détecter rapidement une mauvaise configuration. Sur un site WooCommerce, testez aussi le panier, la page de paiement et le compte utilisateur. Un simple blocage de fichier JS peut nuire au taux de conversion.

Autres mesures pour sécuriser la structure des dossiers WordPress

La protection de wp-includes est une étape, mais la sécurité WordPress doit être globale. Voici des conseils complémentaires :

• Gardez WordPress à jour plutôt que de masquer la version.
• Supprimez les thèmes et plugins inutilisés.
• Choisissez un nom d’utilisateur admin difficile à deviner.
• Mettez en place l’authentification à deux facteurs.
• Limitez l’accès à XML-RPC si vous ne l’utilisez pas.
• Ajoutez un rate limit ou une vérification supplémentaire sur wp-login.php.
• Planifiez des sauvegardes automatiques quotidiennes et testez la restauration.
• Activez HTTPS partout : sans SSL, les identifiants sont exposés.

SSL ne bloque pas directement l’accès à wp-includes, mais sécurise les sessions, les formulaires et l’administration. Il est donc une couche essentielle de sécurité. À ce sujet, découvrez acheter un certificat SSL et Installation de SSL gratuit pour protéger votre site.

Quand demander une assistance professionnelle ?

Ajouter une règle .htaccess sur Apache est à la portée de la plupart des utilisateurs. Mais si vous gérez une configuration Nginx avancée, un multisite, une boutique WooCommerce, un site d’actualité à fort trafic ou un portail d’entreprise, faites-vous accompagner. La sécurité doit être technique et garantir la continuité d’activité.

Demandez l’aide d’un expert si :

• Vous hébergez plusieurs sites WordPress sur le même serveur.
• Vous utilisez Nginx, Varnish, CDN et WAF en même temps.
• Après une modification, vous observez une hausse des erreurs 403, 404 ou 500.
• Votre site a déjà été infecté par un malware.
• Votre système gère des paiements, des membres ou des données personnelles.

Un hébergement sécurisé, une bonne isolation, des sauvegardes régulières et une assistance technique sont des facteurs clés pour la sécurité WordPress. Ne vous limitez pas à l’espace disque : vérifiez aussi la sauvegarde, le firewall, le support PHP, la gestion SSL et la qualité du support. Pour choisir la bonne offre, lisez Packages d'hébergement Hostragons ou Migration de site WordPress.

Conclusion

Pour sécuriser la structure des dossiers WordPress, la meilleure pratique n’est pas de bloquer tout wp-includes, mais d’empêcher l’exécution directe des fichiers PHP et de désactiver la liste des fichiers. Les règles .htaccess (Apache) ou location (Nginx) sont faciles à mettre en place, à condition de sauvegarder avant toute modification et de tester ensuite l’administration et le front-office.

En résumé : ne bloquez pas les fichiers statiques, limitez l’accès PHP, désactivez l’indexation, vérifiez les droits d’accès et pratiquez la mise à jour régulière. Pour une infrastructure WordPress fiable, explorez les solutions Hostragons pour l’hébergement, le domaine et le SSL, ou demandez un accompagnement personnalisé.

FAQ – Questions fréquentes

Est-il sûr de bloquer complètement le dossier wp-includes ?

Non, ce n’est pas recommandé. wp-includes contient des fichiers JS, CSS et autres assets nécessaires à WordPress. Un blocage total peut casser l’affichage ou l’administration. Privilégiez le blocage des fichiers PHP uniquement.

Que faire si je reçois une erreur 500 après avoir ajouté une règle .htaccess ?

Commencez par supprimer la règle ou restaurer le .htaccess sauvegardé. Vérifiez la syntaxe de la règle. Si cela ne suffit pas, consultez les logs d’erreur de l’hébergeur ou demandez de l’aide au support technique.

Le fichier .htaccess fonctionne-t-il sur Nginx ?

Non. .htaccess est propre à Apache/LiteSpeed. Sur Nginx, utilisez une règle location dans la configuration du serveur, puis testez avec nginx -t.

Cette protection rend-elle mon site WordPress totalement sécurisé ?

Non. Bloquer l’exécution PHP dans wp-includes est une étape importante, mais la sécurité repose aussi sur les mises à jour, les mots de passe robustes, l’authentification à deux facteurs, SSL, sauvegardes, firewall et droits d’accès.

Dois-je ajouter une règle wp-includes si j’utilise déjà un plugin de sécurité ?

Tout dépend du plugin : certains ajoutent la règle .htaccess, d’autres protègent seulement côté application. Bloquer l’accès PHP au niveau serveur, sans conflit, reste la solution la plus solide.