Les attaques qui passent par l’upload ne font pas toujours de bruit. Souvent, elles commencent par quelque chose de banal: un formulaire de contact mal protégé, une page de médias laissée ouverte, un champ d’import qui accepte trop large, ou un plugin qui n’a pas surveillé ce qu’il fait réellement avec les fichiers reçus. Puis, progressivement, l’assaillant transforme un simple transfert de document en porte d’entrée.
Sécuriser l’upload de documents, c’est une manière concrète de renforcer la sécurité WordPress sans “tout bloquer”. L’objectif n’est pas d’empêcher les utilisateurs d’ajouter des images, des PDFs ou des documents utiles. L’objectif est de rendre les fichiers non fiables inexploitables, et de réduire drastiquement les chemins où un fichier malveillant pourrait devenir exécutable, interprété, ou réutilisé.
Dans la suite, je vais détailler les points à traiter, les pièges fréquents, et une méthode pragmatique pour vérifier votre configuration.
Comprendre ce qui se joue dans un upload
Quand WordPress reçoit un fichier via l’interface d’administration, il s’appuie sur plusieurs étapes: validation, stockage dans le dossier uploads, enregistrement des métadonnées, puis génération éventuelle de variantes (images) et rendu dans l’interface.
Le dossier de médias est donc un nœud sensible. Même si WordPress “filtre” une partie de ce que vous envoyez, il reste des risques classiques:
- Un fichier peut être enregistré avec un nom trompeur, ou une extension qui ne correspond pas au contenu. Le serveur web peut être configuré pour exécuter certains fichiers dans le répertoire uploads (selon la stack, Apache, Nginx, types de handlers). Une application ou un plugin peut exposer des endpoints d’upload, d’import, ou de restauration qui acceptent trop. Les règles de validation côté PHP et côté serveur peuvent diverger, et c’est là que naissent les contournements.
Le point clé, c’est que vous voulez “verrouiller” à plusieurs étages: le navigateur, l’application WordPress, et le serveur. Un seul verrou suffit rarement.
Vérifier les bases: qui peut uploader, et comment
Avant même de toucher aux réglages techniques, j’aime commencer par les permissions. Dans beaucoup de sites, le problème n’est pas une faille compliquée, c’est un excès de confiance côté rôles.
Sur WordPress, l’upload est une action qui peut être autorisée à des rôles “auteurs”, “éditeurs” ou “contributeurs”. Si vous n’avez pas réellement besoin que certains comptes déposent des documents, réduisez cette capacité.
Un détail souvent oublié: même si vous limitez les formats autorisés, un utilisateur disposant du droit d’upload peut aussi charger des fichiers “légalement” acceptés, puis abuser d’une autre surface, par exemple un rendu trop permissif, une intégration en page, ou une fonctionnalité d’import.
Mon approche sur les sites gérés: je coupe l’accès à l’upload aux rôles qui n’en ont pas besoin. Ensuite, je m’assure que la médiathèque ne devient pas un “conteneur” où tout le monde peut déposer n’importe quoi. Si vous gérez des contributeurs, le mieux est de leur offrir un flux de travail clair, plutôt que de leur donner une liberté totale.
Faire correspondre extension, type MIME et contenu
Un fichier “image.jpg” peut contenir autre chose qu’une image. Un fichier “document.pdf” peut être un binaire déguisé. Le filtre le plus sain n’est pas seulement l’extension, c’est la combinaison des indices: l’extension, le type MIME déclaré, et le contenu réel.
Côté WordPress, vous pouvez faire plusieurs choses:
1) Limiter les extensions acceptées.
2) Refuser les types MIME non attendus. 3) Éviter les cas où le serveur interprète des formats inattendus.Selon votre version et votre stack, les réglages peuvent varier, mais le principe reste identique: “si ce n’est pas cohérent, on rejette”.
Si vous utilisez un plugin de sécurité, il peut proposer des contrôles autour de la validation des uploads. Je reste prudent: les plugins changent, les options varient, et certaines configurations peuvent casser des usages légitimes (par exemple des PDFs avec des métadonnées atypiques). L’important est de tester sur votre site avec de vrais fichiers de votre quotidien.
Protéger le dossier uploads contre l’exécution
C’est le cœur de la sécurisation. Même si WordPress ne permet pas d’exécuter du code via l’interface, un serveur mal configuré peut exécuter des fichiers dans le répertoire uploads selon ses règles.
Cas Apache
Le mécanisme classique consiste à empêcher l’exécution des fichiers potentiellement dangereux dans le dossier uploads, via une règle dans un fichier .htaccess. L’idée: bloquer l’accès direct aux scripts et forcer un traitement inoffensif.
Un exemple typique, à adapter soigneusement selon votre configuration et votre dossier exact:
RewriteEngine On RewriteBase / # Bloquer l'exécution de fichiers potentiellement interprétés RewriteRule ^wp-content/uploads/.*\.(php|php5|phtml|pl|py|cgi|asp|aspx|jsp|sh)$ - [F,L]Selon votre environnement, vous pouvez aussi utiliser des règles Options -ExecCGI ou des directives spécifiques. Le point important est de vérifier que la règle correspond bien au chemin réel de vos médias et qu’elle ne casse pas des formats autorisés.
Cas Nginx
Avec Nginx, c’est souvent encore plus net, car on peut définir un location qui empêche l’exécution dans wp-content/uploads. Là aussi, l’idée est d’empêcher le serveur d’interpréter quoi que ce soit dans ce répertoire comme du code exécutable.
Un exemple simplifié, à ajuster:
Location ~* ^/wp-content/uploads/.*\.(php|phtml|php5)$ Deny all;Dans la vraie vie, on peut aller plus loin, en “désactivant” les handlers pour les extensions sensibles dans ce dossier, ou en s’assurant que le bloc de configuration des uploads ne route pas vers PHP-FPM.
Attention aux hébergements “exotiques”
Certains hébergeurs ajoutent des couches. Parfois, votre .htaccess n’est pas autorisé, ou bien modifié. Parfois, l’exécution est contrôlée ailleurs. C’est pour ça que je recommande un test simple: tenter l’upload d’un fichier “dangereux” inoffensif (par exemple un faux fichier de code qui contient juste du texte), puis vérifier si le serveur le sert ou s’il le bloque correctement. Si le fichier se télécharge, c’est déjà mieux que s’il s’exécute, mais idéalement on veut un refus explicite.
Contrôler la taille et le rythme d’upload
Un fichier énorme et une rafale d’essais donnent à un attaquant plus d’opportunités, même si les types sont correctement filtrés. Les “uploads” servent aussi à remplir de l’espace disque, provoquer des erreurs, et déclencher des comportements inattendus.
Les limites se jouent sur plusieurs niveaux: réglages PHP, limites du serveur, et parfois paramètres applicatifs. Sans entrer dans des valeurs “magiques”, retenez ceci:
- Fixez une limite de taille réaliste pour vos besoins. Si vous n’avez pas besoin d’envoyer 200 Mo, ne laissez pas passer. Fixez une limite de capacité pour éviter les abus. Surveillez les pics. Un site e-commerce avec des pics d’upload en journée n’a pas le même profil qu’un blog statique.
Là encore, c’est un compromis. Une limite trop stricte casse des usages légitimes. Une limite trop permissive rend les abus plus rentables.
Nettoyer les noms de fichiers et réduire l’impact
Même quand WordPress stocke proprement le fichier, le nom compte. Un nom peut contenir des caractères qui compliquent le traitement, ou des séquences trompeuses.
WordPress renomme souvent les médias lors de l’upload, mais pas toujours selon les cas. Et certains plugins importent ou déplacent des fichiers, ce qui peut contourner vos garde-fous.
Ce que je fais en pratique:
- M’assurer que les noms problématiques sont normalisés. Éviter d’exposer des liens directs non contrôlés. Surveiller les cas où un plugin importe des fichiers depuis l’extérieur.
Le but n’est pas de “rendre le nom joli”. Le but est d’empêcher les surprises côté serveur et côté rendu.
Diminuer l’angle mort des plugins d’upload
Un point que j’ai vu maintes fois: WordPress est plutôt bon dans ses propres règles, mais un plugin peut ajouter sa logique et ses failles.
Exemples d’angles morts typiques:
- Importeurs CSV, systèmes de formulaires, outils de “drag and drop” personnalisés. Plugins de médias, bibliothèques, carrousels, ou galeries qui manipulent des fichiers. Outils de restauration ou de migration qui réinjectent des médias.
La démarche la plus efficace consiste à repérer quel composant accepte réellement des uploads. Sur un site “standard”, l’interface médias est évidente. Sur un site “chargé”, ce n’est pas toujours le cas.
Voici une mini-checklist pour cadrer le diagnostic, sans tomber dans l’exhaustivité impossible:
- Identifier les formulaires ou pages où un utilisateur peut envoyer un fichier Lister les plugins qui “reçoivent” ou “importent” des fichiers Vérifier, pour chaque plugin, quels types de fichiers sont réellement acceptés Contrôler les limites de taille et le comportement en cas de fichier refusé Mesurer ce qui se passe quand l’upload échoue (messages, codes d’erreur, logs)
Cette étape vous évite de sécuriser “le mauvais endroit”. On renforce la sécurité WordPress en ciblant l’endroit où l’attaque a le plus de chances de passer.
Durcir WordPress avec une politique de médias plus stricte
WordPress permet d’ajouter des types de fichiers autorisés via des filtres, des plugins, ou des réglages. La tentation est souvent de “tout autoriser pour que ça marche”.
Sur le long terme, cette habitude revient cher. Chaque nouveau type accepté augmente la surface d’attaque, surtout si le site a des comptes multiples ou une activité d’upload fréquente.
Un bon réflexe: définir une politique de médias. Ce que vous gardez, c’est ce que vous utilisez vraiment. Tout le reste, vous le faites passer par un workflow plus sûr, par exemple une conversion avant dépôt, ou un téléchargement qui passe par un traitement dédié.
Si votre site utilise des documents spécifiques, vous pouvez en général vous limiter à des formats courants, comme images, PDF, et éventuellement des fichiers bureautiques selon votre besoin réel. Les formats “rares” ou “exotiques” sont des candidats classiques à être retirés.
Le point délicat, ce sont les comportements de compatibilité. Un format “rare” peut être légitime, mais si vous ne l’utilisez pas, il n’a pas sa place dans les droits d’upload de masse.
Empêcher l’accès direct à certains fichiers et limiter la lecture
Même quand l’exécution est empêchée, un fichier peut rester accessible publiquement. Si vous autorisez des documents sensibles, vous devez décider si ces documents doivent être publics, ou protégés.
Pour des médias destinés à l’illustration, le public est logique. Pour des documents, les choses sont plus nuancées.
Des stratégies existent, par exemple:
- Stocker les documents dans un répertoire protégé, ou derrière une couche d’authentification. Utiliser des mécanismes de limitation d’accès si votre site et votre stack le permettent. Éviter de mettre des fichiers sensibles en accès direct si vous n’avez pas besoin.
Je me méfie particulièrement des fichiers uploadés “par défaut” qui ne sont pas destinés à être consultés par tout le monde. Les fuites ne viennent pas toujours d’une exécution. Elles viennent parfois d’une mauvaise hypothèse sur la confidentialité.
Surveiller, journaliser, et vérifier régulièrement
Sécuriser une fois ne suffit pas, parce que le site change. Un nouveau plugin est ajouté, une règle serveur est ajustée, un rôle est modifié. Et un jour, un comportement “normal” devient un comportement exploitable.
La meilleure sécurité, c’est celle que vous pouvez observer.
Concrètement, je recommande:
- Consulter les journaux des erreurs et les logs liés aux uploads (là où votre hébergeur les expose). Vérifier les événements récents: échecs d’upload, tentatives rejetées, pics de volume. Contrôler le dossier uploads pour voir ce qui y atterrit après changements.
Je n’ai pas besoin de faire de la paranoïa, mais j’aime repérer les signaux faibles. Si vous voyez des extensions inattendues, même rejetées, c’est un indicateur de tentative d’attaque, ou de mauvaise configuration.
Tester sans casser
Un test trop intrusif peut déclencher des alertes et bloquer du trafic. Un test trop léger ne révèle rien. Il faut un équilibre.
Voici une manière simple de tester votre politique de manière réaliste, sans lister une procédure interminable:
- Choisissez un fichier “image” réellement valide, et un fichier “faux” avec une extension sensible mais contenu texte. Essayez l’upload avec un rôle non privilégié, puis avec un rôle autorisé. Vérifiez le comportement: message d’erreur, présence du fichier en médiathèque, et si l’URL directe renvoie correctement (téléchargement, refus, ou 404).
Le but est de vérifier non seulement “est-ce refusé”, mais aussi “comment ça échoue”, car un échec mal géré peut exposer des informations internes ou créer un état incohérent.
Composer: ce qui marche le mieux quand on assemble les couches
Quand on fait les choses correctement, on obtient un système résilient: WordPress filtre, le serveur empêche l’exécution, les tailles limites réduisent l’abus, et la surveillance capte les comportements anormaux.
Le tableau mental que j’utilise ressemble à une décision de sécurité, pas à une seule action. Si vous devez choisir une priorité pour un site “déjà en production”, je vous propose ce raisonnement:
- Si vous n’avez qu’une priorité immédiate, verrouillez l’exécution dans wp-content/uploads côté serveur. Ensuite, réduisez les types acceptés et assurez une validation cohérente. Puis, contrôlez qui peut uploader, et avec quel rôle. Enfin, surveillez et testez les changements.
Cette approche évite l’erreur fréquente: “j’ai mis un plugin, donc c’est bon”. La réalité, c’est que la sécurité des uploads est un ensemble, pas un gadget.
Cas particuliers: multisite, CDN, et environnements de staging
Sur un WordPress multisite, l’upload se complique. Les règles peuvent être différentes selon les sites, et les répertoires varient. Les protections côté serveur doivent être appliquées au bon chemin, pas uniquement sur un modèle.
Avec un CDN, vous devez aussi tenir compte de la manière dont les fichiers sont servis. Le CDN peut cacher des erreurs, ou servir un contenu sans que vous voyiez immédiatement les effets de vos règles serveur. Ici, on teste en contrôlant vraiment la réponse (statut HTTP, comportement de téléchargement, et absence d’exécution).
En staging, c’est plus simple pour tester. Mais attention: un staging n’est pas toujours identique en configuration serveur. Si vous ne pouvez pas reproduire exactement, testez au moins l’aspect “serré” sur le serveur de production avant d’être trop confiant.
Les compromis à accepter (et ceux à refuser)
Sécuriser l’upload, c’est aussi gérer le quotidien.
Vous aurez probablement des utilisateurs qui veulent envoyer “le fichier qu’ils ont sous la main”. Votre politique ne doit pas les punir inutilement, mais elle doit rester ferme.
Parfois, il faudra dire non à certains formats, même si vous “pouvez” techniquement les autoriser. L’acceptation par défaut est rarement une bonne stratégie. À l’inverse, refuser un format très utile peut créer du contournement interne, par exemple via un partage de fichier externe qui n’est pas mieux sécurisé.
Dans ces situations, j’applique une règle pragmatique: si un format est légitime dans votre activité, vous gardez une voie propre, soit via conversion, soit via un traitement plus contrôlé. Si un format n’est pas nécessaire, vous le retirez.
Plan d’action concret en deux phases
Pour rendre l’ensemble praticable, voici un plan d’action en deux phases, avec un ordre qui limite le risque de casser du contenu existant.
Phase 1: durcir sans changer votre expérience utilisateur
Vous cherchez https://gardewp.fr/securite-wordpress/ d’abord à réduire l’exécution et les angles morts serveur.
- Vérifier la configuration serveur pour empêcher l’interprétation de fichiers exécutables dans uploads. Harmoniser les règles autour des extensions sensibles. Vérifier que vos règles ciblent bien le bon répertoire.
Cette phase est généralement compatible avec une expérience utilisateur inchangée, car elle ne touche pas au “quoi” mais au “où” et au “comment”.
Phase 2: resserrer les types et les droits
Une fois l’exécution bloquée, vous pouvez resserrer ce que WordPress et votre site acceptent réellement.
- Réduire la liste des types autorisés à ceux réellement utilisés. Contrôler les rôles qui uploadent. Mettre en place une validation plus cohérente (extension et type).
Là, vous pouvez rencontrer des surprises: un plugin qui attend un format particulier, un utilisateur qui stocke des documents dans un type non standard. Le bon réflexe est de tester sur un petit périmètre, puis d’ajuster.
Ce que je recommande de garder en tête
Sécuriser l’upload de documents n’est pas un projet “one shot”. C’est un sujet vivant, car votre parc applicatif évolue.
Si je devais résumer les idées qui tiennent le mieux sur la durée, ce sont celles-ci:
Vous devez empêcher l’exécution dans uploads par la configuration serveur. Vous devez faire correspondre ce qui est envoyé, ce qui est déclaré, et ce qui est attendu. Vous devez réduire les droits d’upload et surveiller les comportements anormaux. Et vous devez tester vos changements, parce que la sécurité qui casse votre production est une sécurité inutilisable.
Au final, c’est la combinaison de ces choix qui renforce la sécurité WordPress. Pas la promesse d’un réglage unique.
Si vous voulez, décrivez votre stack (Apache ou Nginx), si vous êtes en multisite, et la liste des formats que vous autorisez aujourd’hui. Je peux vous proposer une stratégie de durcissement adaptée, avec les points de contrôle à vérifier pour éviter les mauvaises surprises.