Quand un site WordPress prend du volume, le dossier uploads devient le carrefour de presque tout: images, PDF, fichiers ZIP, documents divers. C’est aussi l’endroit où un attaquant tente le plus souvent d’obtenir un impact concret, parce qu’un fichier “qui ne devrait pas s’exécuter” peut, selon la configuration serveur, devenir un point d’entrée.
Le plugin Durcir WordPress vise justement à réduire la surface d’attaque. Parmi les mesures utiles, l’objectif de “ne pas exécuter de fichiers” dans wp-content/uploads est particulièrement important. Ce n’est pas une mesure cosmétique, c’est une barrière de base. Et, selon votre hébergement, elle peut dépendre autant de Durcir que de la configuration webserver.
Je vais donc détailler ce que vous cherchez à obtenir, pourquoi ça ne se limite pas à un bouton dans l’admin, et comment vérifier que l’exécution de PHP dans uploads est réellement bloquée.
Le problème concret: pourquoi uploads peut devenir exécutable
WordPress stocke les médias dans wp-content/uploads/. Sur un serveur bien configuré, le navigateur récupère ces fichiers comme du contenu statique. Un .jpg ou un .pdf sont servis sans interprétation.
Le risque arrive quand quelqu’un parvient à déposer un fichier malveillant dans uploads avec une extension interprétée par le serveur. Les scénarios typiques sont:
- un upload qui n’est pas bloqué parce que l’extension est trompeuse (ou parce que la vérification côté WordPress est contournable selon le contexte), un fichier déjà présent sur le serveur après compromission (exécution de scripts déjà là), un fichier dont l’interprétation dépend de règles webserver (cas de gestion PHP au niveau global, ou règles trop permissives sur certains chemins).
Si le serveur est configuré pour envoyer tout vers PHP, ou si des règles de réécriture autorisent l’exécution, un fichier comme wp-content/uploads/quelquechose.php peut devenir exécutable. Dans une défense en profondeur, on cherche à empêcher cette interprétation.
Ce point est central: même avec un durcissement WordPress, si le serveur laisse PHP s’exécuter dans uploads, vous avez une couche de défense de moins au moment où ça compte.
Ce que Durcir WordPress peut faire (et ce qu’il ne peut pas faire seul)
Durcir WordPress est utile parce qu’il automatise des réglages et applique des contrôles côté WordPress. Selon la version du plugin et votre configuration, il peut agir sur:
- des règles .htaccess quand Apache est utilisé, des protections sur l’upload (validation des extensions, durcissement de endpoints, limitation de vecteurs), des paramètres de sécurité liés à WordPress.
Mais il faut être lucide: un plugin ne remplace pas la configuration du webserver. Si vous êtes sur Nginx ou sur un stack particulier, Durcir peut ne pas gérer le même niveau de détail qu’une configuration d’Apache via .htaccess.
C’est pour ça que la bonne approche consiste à combiner:
1) les réglages “WordPress side” (ce que Durcir fait souvent assez bien), 2) les règles “webserver side” qui empêchent réellement l’exécution dans uploads, 3) des tests de validation pour confirmer le comportement https://gardewp.fr/securite-wordpress/ réel.
Comprendre la cible: qu’est-ce que “empêcher l’exécution” veut dire exactement
Il ne suffit pas de dire “bloquer PHP”. En pratique, vous voulez éviter plusieurs choses à la fois:
- le serveur ne doit pas interpréter un fichier comme PHP s’il se trouve sous wp-content/uploads, le serveur ne doit pas appliquer des règles qui transmettent ce contenu à PHP, les exceptions involontaires (règles plus haut dans l’arborescence, alias, réécritures) ne doivent pas réintroduire de l’exécution.
Sur Apache, la logique passe souvent par des directives dans .htaccess pour désactiver l’interprétation PHP dans ce dossier.
Sur Nginx, ce n’est pas le même mécanisme. Il faut souvent ajuster les location pour empêcher l’interprétation de fichiers PHP sous uploads.
Enfin, il y a une dimension WordPress. Même si le serveur ne sait pas exécuter, un attaquant peut quand même injecter des fichiers pour déclencher d’autres effets (XSS via fichiers HTML servis, ou scripts dans des contextes inattendus). La couche “upload hardening” est donc complémentaire.
La méthode fiable: bloquer au niveau webserver, puis consolider avec Durcir
Avant de toucher à quoi que ce soit, faites un point de départ raisonnable.
- Votre serveur utilise probablement Apache avec .htaccess, ou Nginx (parfois derrière un proxy). Votre environnement peut être mutualisé, auquel cas vous ne contrôlez pas toujours le serveur entier. Mais vous avez souvent une possibilité d’ajouter des règles locales (via .htaccess sur Apache, ou via configuration Nginx du panel d’hébergement). Vous avez peut-être un CDN ou un cache. Un test doit viser l’origine quand c’est possible, ou au minimum vérifier sans ambiguïté.
L’objectif suivant est simple: si vous tentez d’accéder à un fichier exécutable dans uploads, vous devez obtenir une réponse “statique” ou “interdit”, pas une exécution.
Exemple de test réaliste
Sans avoir besoin de “charger” des outils dangereux, vous pouvez déposer temporairement un fichier inoffensif de test, par exemple:
- wp-content/uploads/test-security-php.php contenant un texte statique, puis tester l’URL correspondante.
S’il est exécuté (par exemple si le fichier renvoie une sortie de script), votre blocage n’est pas en place. S’il renvoie une erreur 403/404 ou s’il sert le fichier comme texte (selon politique), vous êtes sur une bonne voie. L’idéal est d’avoir un blocage explicite (interdit) plutôt qu’une simple non-interprétation, car c’est souvent plus cohérent en durcissement.
Faites ce test seulement sur un environnement de contrôle ou pendant une fenêtre de maintenance. Le but n’est pas de laisser un fichier “PHP test” sur le site.
Si vous êtes sur Apache: le rôle typique de .htaccess
Sur Apache, la façon classique d’empêcher l’exécution dans uploads consiste à ajouter des règles dans .htaccess (soit au niveau du dossier wp-content/uploads, soit plus haut avec une condition).
Je ne vous donne pas de recette aveugle, parce que les hébergeurs ont parfois des particularités. Mais le principe reste: forcer l’absence de traitement PHP pour les fichiers dans uploads.
Vous verrez souvent des directives basées sur mod_php, ou sur la gestion PHP via SetHandler. Dans beaucoup d’installations modernes, PHP-FPM est utilisé et géré via des règles de proxy avec FilesMatch ou des patterns.
Ce que vous cherchez, conceptuellement, c’est une règle qui dit: “si le chemin est dans uploads et si le fichier finit par .php, ne passe pas à PHP”.
Voici à quoi peut ressembler l’idée (à adapter à votre environnement):
- un bloc qui cible wp-content/uploads/, puis un pattern sur \.php$, qui renvoie 403 ou désactive le handler.
Si Durcir WordPress crée automatiquement ces règles, vérifiez le résultat effectif dans votre .htaccess (et dans le bon dossier). Sur certains hébergements, il peut exister plusieurs .htaccess et l’ordre d’évaluation compte.
Piège courant: une règle trop générale ailleurs
J’ai déjà vu des cas où l’équipe pensait avoir “bloqué PHP dans uploads”, mais une règle globale, plus haut dans l’arborescence, transmettait quand même les requêtes à PHP. Résultat: la règle locale n’était pas suffisante.
C’est pour ça qu’il faut valider en test, pas uniquement “par lecture de configuration”. La réalité dépend souvent de la combinaison de modules, de règles existantes, et de l’ordre.
Si vous êtes sur Nginx: pourquoi Durcir peut ne pas suffire
Sur Nginx, .htaccess n’existe pas dans la même logique. Les règles doivent être dans la configuration Nginx (ou dans un fragment géré par votre hébergeur).
Pour empêcher l’exécution de PHP dans uploads, la correction typique consiste à:
- s’assurer que location ~ \.php$ ne match pas ou ne transmet pas les fichiers venant de wp-content/uploads, ou créer une règle location spécifique pour uploads avant la règle PHP générique.
Si votre hébergeur propose un “gestionnaire de configuration” (par exemple via panel), vous devrez ajuster selon leur modèle. Sinon, vous devrez demander au support.
Dans ce contexte, Durcir WordPress peut améliorer la sécurité côté WordPress, mais ne peut pas garantir l’absence d’exécution si le serveur Nginx laisse de toute façon passer.
Vérifier que le blocage fonctionne vraiment
Un bon durcissement n’est pas une croyance, c’est un comportement observé.
Voici un point de contrôle simple, à faire dans l’ordre, sans multiplier les manipulations:
- testez une URL d’un fichier .php placé temporairement dans wp-content/uploads et observez la réponse, contrôlez que le fichier n’est pas interprété (pas de sortie PHP), vérifiez le code HTTP (souvent 403 ou 404 selon la règle), vérifiez aussi l’accès direct via paramètres de requête typiques (sans exagérer, juste pour détecter un contournement évident), relisez les règles générées par Durcir dans .htaccess (si Apache) et confirmez qu’elles ciblent bien uploads.
Cette validation prend moins de temps que de “deviner” et évite des surprises en production.
Et les uploads “dangereux” côté WordPress, dans tout ça ?
Même si vous bloquez l’exécution, le durcissement WordPress autour des uploads reste crucial. Un attaquant qui n’a plus la possibilité d’exécuter du PHP peut encore:
- déposer du contenu qui provoque des effets côté navigateur (si vous servez des fichiers HTML ou SVG dans certains contextes), remplir l’espace disque ou faire des attaques de type déni de service logique, tenter d’abuser de chemins inattendus (selon configuration et versions), chercher un autre vecteur dans l’écosystème (thèmes, plugins, REST API).
Durcir WordPress a souvent un rôle à jouer sur ces points, via des contrôles et des durcissements. Pour uploads, ça peut inclure une meilleure hygiène de validation. Mais attention, chaque validation a ses compromis.
Par exemple, certains sites ont besoin d’accepter des formats “bizarres” pour une raison métier, comme des fichiers d’un format interne, ou des archives. Si vous durcissez à l’extrême, vous risquez de casser une partie du flux documentaire.
Le bon équilibre consiste à durcir ce qui est rarement nécessaire (les formats exécutables) et à garder une politique claire pour le reste. Et surtout, à documenter ce qui est autorisé et pourquoi.
Les compromis qui reviennent souvent
Empêcher l’exécution dans uploads, c’est généralement une bonne idée, mais il y a des angles pratiques:
1) Certains plugins ou workflows s’appuient, de manière contestable, sur des fichiers exécutables dans uploads. C’est rare, mais ça existe, surtout dans des installations où des scripts ont été ajoutés “en vitesse” en dehors des bonnes pratiques. Bloquer l’exécution peut casser ces usages.
2) Les hébergeurs ont parfois des restrictions particulières sur les directives .htaccess autorisées. Une règle que vous mettez peut être ignorée. Dans ce cas, votre validation par test est indispensable.
3) Si votre site utilise un stockage externe (S3, équivalent) pour les médias, la logique “uploads sur le serveur” change. Le blocage local sur wp-content/uploads peut ne pas correspondre à ce qui est servi depuis l’URL publique. Vous bloquez alors l’exécution sur l’emplacement d’origine, mais le contenu est peut-être délivré ailleurs.
4) Les caches et CDNs peuvent masquer le comportement réel. Un test doit être mené de manière à éviter de conclure sur la base d’une réponse mise en cache.
Ces points ne visent pas à décourager, juste à cadrer la réalité: sécurité, oui, mais avec méthode.
Comment intégrer Durcir WordPress sans perdre le contrôle
Mon approche quand j’intègre un plugin de durcissement sur un site existant, c’est de traiter Durcir WordPress comme un outil de consolidation, pas comme un fournisseur de vérité.
Concrètement:
- activez les options qui correspondent à votre environnement (Apache versus Nginx), évitez d’empiler des mesures contradictoires si vous avez déjà des règles serveur en place, regardez ce que le plugin écrit ou modifie (en particulier les règles générées pour .htaccess), testez après chaque changement significatif, pas seulement après la mise en prod.
Si le plugin modifie .htaccess, gardez une trace du contenu avant. En cas d’effet de bord, savoir “ce qui a changé” accélère le diagnostic.
Exemple de configuration à adapter: politique d’interdiction explicite
Sur un site WordPress standard avec Apache, l’idée la plus saine est souvent une interdiction explicite de l’exécution de fichiers .php dans wp-content/uploads, sans toucher au reste du service statique.
Si vous devez appliquer la règle vous-même, votre cible n’est pas “casser toutes les extensions”. C’est précisément de neutraliser l’interprétation PHP.
Pour cadrer votre action, voici les éléments que vous devez vérifier dans la règle (ou via la génération de Durcir):
- Ciblage correct du chemin wp-content/uploads (y compris sous-dossiers). Ciblage correct des extensions interprétées par le serveur (souvent .php seul, parfois d’autres handlers selon votre stack). Code de réponse attendu (403 ou 404, mais pas un contenu exécuté). Absence de contournement trivial via réécriture. Compatibilité avec les règles existantes dans d’autres .htaccess.
Si vous avez un doute, basez-vous sur le test HTTP réel plutôt que sur l’intuition.
Ce que je recommande en pratique sur un site “en production”
Si votre objectif est uniquement de “ne pas exécuter dans uploads” sans rendre l’opération risquée, je ferais:
1) Activer les protections de Durcir WordPress pertinentes pour le durcissement des uploads (côté WordPress). 2) Valider ensuite la partie serveur avec un test simple sur une URL d’un fichier .php temporaire dans uploads. 3) Si le test échoue, intervenir au niveau serveur (Apache via .htaccess, ou Nginx via configuration), puis retester. 4) Repasser en mode normal en supprimant tout fichier de test. 5) Garder une sortie claire pour le cas où un plugin ou un script interne dépendrait d’une exécution dans ce dossier, et envisager une alternative propre (mettre le code ailleurs que dans uploads, et éviter l’exécution de fichiers uploadés).
Ce séquencement évite de transformer un durcissement en lot de corrections aveugles.
Surveillance après durcissement: les signaux à ne pas ignorer
Après avoir mis en place le blocage, je surveille deux familles de signaux:
- Les journaux webserver et logs applicatifs, pour vérifier qu’on reçoit bien des erreurs d’accès et pas des exécutions. Les événements inhabituels liés à l’upload, comme un nombre anormal de tentatives ou des refus répétés. Cela ne “prouve” rien à lui seul, mais ça donne un contexte.
Si vous constatez au contraire que des tentatives d’upload continuent et que des fichiers se retrouvent quand même dans uploads, c’est que la couche WordPress de validation doit être renforcée, ou qu’il existe une voie différente (compromission existante, compte admin, token volé, etc.). Le blocage d’exécution est une barrière, pas une solution complète si l’attaque a déjà franchi d’autres étapes.
En résumé opérationnel
Le dossier wp-content/uploads doit idéalement rester un espace de contenus statiques. Durcir WordPress aide à réduire les risques au niveau WordPress, mais pour empêcher l’exécution, le nerf de la guerre reste la configuration webserver et la validation par test.
Si vous obtenez, après durcissement, une réponse du type 403 ou 404 quand vous essayez d’accéder à un fichier .php placé dans uploads, vous êtes sur la bonne trajectoire. Si vous voyez une exécution ou une sortie PHP, il faut revenir aux règles serveur et aux combinaisons de réécriture, puis retester.
C’est ce mélange de “bon réglage” et de “test qui prouve” qui fait la différence, surtout sur des environnements réels, avec des hébergeurs différents et des stacks parfois hétérogènes.
Si vous me dites sur quel serveur vous êtes (Apache avec .htaccess ou Nginx), et si Durcir WordPress vous indique une modification dans .htaccess ou une option spécifique liée à uploads, je peux vous aider à interpréter le résultat attendu et à formuler la règle la plus compatible avec votre configuration.