En 2027, la sécurité WordPress tient à une courte liste d’habitudes : tenir à jour le cœur, les plugins et les thèmes, verrouiller les connexions avec des mots de passe robustes et la double authentification, supprimer ce qui ne sert pas, et conserver hors du serveur des sauvegardes testées. Presque toutes les attaques réussies contre un site WordPress passent par l’une de ces portes ouvertes, pas par une faille exotique de WordPress lui-même.
Dernière mise à jour : 20 octobre 2026.
Ce guide couvre les principales menaces, un tableau des parades et de l’effort que chacune demande, une checklist de sécurisation numérotée, les règles de l’UE qui concernent votre site, et que faire dans les premières heures d’un piratage.
WordPress est-il sécurisé ?
Le cœur de WordPress est maintenu par une importante équipe sécurité, reçoit par défaut des mises à jour mineures automatiques et fait l’objet d’un examen permanent. En lui-même, c’est une base solide. Le risque vient de ce qu’on y ajoute et de la façon dont il est exploité : plugins et thèmes de multiples auteurs, comptes administrateur aux mots de passe faibles, versions de PHP anciennes, hébergement bon marché sans isolation entre les sites, et personne pour surveiller.
En bref : WordPress est aussi sûr que la façon dont il est construit et maintenu. Un site sobre, avec peu de plugins bien choisis, des logiciels à jour et des accès maîtrisés, est une cible difficile. Un site avec quarante plugins, dont cinq abandonnés, et un mot de passe administrateur partagé est une cible facile. La différence tient rarement à la plateforme ; elle tient au soin qu’on y apporte.
Chez Odduel, agence créative et technologique à Barcelone et São Paulo, nous construisons des sites WordPress avec nos propres thèmes en blocs et le moins de plugins possible, pour la vitesse et parce que chaque plugin est du code auquel il faut faire confiance. Si vous préparez un nouveau site, notre travail de création de sites web commence par cette question : de quoi ce site a-t-il réellement besoin pour fonctionner ?
Quelles sont les principales menaces pour la sécurité de WordPress ?
Les attaques contre WordPress sont pour la plupart automatisées. Des robots parcourent le web à la recherche de faiblesses connues et les testent sur chaque site trouvé : le site d’une petite entreprise a autant de chances d’être sondé qu’un grand. Voici les cinq menaces qui comptent le plus.
Plugins et thèmes obsolètes
C’est la porte d’entrée la plus courante. Une faille est découverte dans un plugin, un correctif sort, les détails deviennent publics, et des robots commencent à tester la faille sur chaque site qui n’a pas fait la mise à jour. Le délai entre le correctif et les premières attaques peut être court. Les plugins abandonnés sont pires : ils ne seront jamais corrigés.
Connexions faibles et mots de passe volés
La page de connexion `/wp-login.php` est publique sur tous les sites. Des robots y testent des mots de passe courants et des mots de passe fuités d’autres services (credential stuffing). Un compte administrateur au mot de passe réutilisé, ou le nom d’utilisateur par défaut « admin », livre tout le site à un attaquant sans la moindre faille.
XML-RPC et autres points d’entrée hérités
XML-RPC est une ancienne interface de publication à distance. La plupart des sites n’en ont plus besoin, mais elle reste activée par défaut et permet à un attaquant de tester de nombreux mots de passe en une seule requête. Il en va de même pour la liste publique des noms d’utilisateur dans l’API REST, qui donne aux robots la moitié de chaque connexion.
Envoi de fichiers
Tout formulaire ou plugin qui accepte des fichiers peut servir à déposer un script sur le serveur. Si le serveur exécute ensuite du PHP depuis le dossier des téléversements, l’attaquant dispose d’une porte dérobée. Formulaires de contact avec pièces jointes, profils utilisateurs et plugins de médias sont les suspects habituels.
Chaîne d’approvisionnement
Un plugin de confiance peut changer de mains. Un nouveau propriétaire, ou un attaquant qui a pris le contrôle du compte de l’auteur, peut publier une mise à jour contenant du code caché sur tous les sites qui l’installent automatiquement. Les plugins et thèmes premium « nulled » (piratés) sont par nature une attaque de la chaîne d’approvisionnement : ils arrivent souvent avec un logiciel malveillant déjà à l’intérieur.
Menaces, parades et effort en un coup d’œil
Le tableau associe chaque menace à la parade qui la neutralise, avec une idée de l’effort nécessaire pour un site type.
| Menace | Parade | Effort |
|---|---|---|
| Plugins et thèmes obsolètes | Mises à jour hebdomadaires, test en préproduction, suppression des plugins abandonnés | Faible, en continu |
| Connexions faibles | Mots de passe uniques, double authentification, limitation des tentatives de connexion | Faible, une fois |
| XML-RPC et listes d’utilisateurs | Désactiver XML-RPC et la liste publique des utilisateurs | Faible, une fois |
| Envoi de fichiers | Bloquer le PHP dans les téléversements, limiter les types de fichiers, analyser les envois | Moyen, une fois |
| Chaîne d’approvisionnement | Peu de plugins, d’auteurs connus, aucun code piraté, revue des mises à jour | Moyen, en continu |
| Compromission du serveur | Hébergement isolé, PHP à jour, pare-feu, droits de fichiers minimaux | Moyen, une fois |
| Perte de données après une attaque | Sauvegardes externalisées, versionnées et testées | Faible, en continu |
La plupart du travail demande peu d’effort. Ce qui coûte cher dans la sécurité WordPress, ce ne sont pas les parades ; c’est le nettoyage quand elles ont été négligées.
Sécuriser un site WordPress : la checklist en dix étapes
Appliquez cette checklist de sécurisation à un nouveau site avant le lancement, et à un site existant comme audit. Suivez-la dans l’ordre : les premières étapes ferment les portes que les attaquants essaient le plus.
- Mettez tout à jour. Cœur, plugins, thèmes et PHP. Activez les mises à jour mineures automatiques du cœur, testez d’abord les mises à jour de plugins sur une copie de préproduction, et fixez un rythme hebdomadaire pour le reste.
- Supprimez ce qui ne sert pas. Effacez les plugins et thèmes inactifs, ne vous contentez pas de les désactiver. Remplacez tout plugin qui n’a reçu aucune mise à jour depuis un an.
- Revoyez les rôles utilisateurs. Donnez à chacun son propre compte, avec le rôle le plus bas qui permet de faire le travail. Les éditeurs n’ont pas besoin d’être administrateurs. Supprimez les comptes des anciens salariés et des agences le jour de leur départ.
- Activez la double authentification. Rendez-la obligatoire au moins pour les administrateurs. Ajoutez des mots de passe robustes et uniques, conservés dans un gestionnaire de mots de passe.
- Limitez les tentatives de connexion. Limitez le débit sur `/wp-login.php` au niveau du serveur ou du pare-feu, et masquez les noms d’utilisateur dans les archives publiques et l’API REST.
- Désactivez XML-RPC sauf si un service dont vous dépendez en a besoin, et désactivez l’édition de fichiers dans l’administration (`DISALLOW_FILE_EDIT`).
- Gardez les sauvegardes hors du serveur. Quotidiennes, versionnées, stockées ailleurs, et restaurées une fois lors d’un test pour savoir qu’elles fonctionnent.
- Ajoutez un pare-feu. Un pare-feu applicatif web, chez l’hébergeur ou devant le site, filtre les attaques connues avant qu’elles n’atteignent WordPress.
- Envoyez des en-têtes de sécurité. HTTPS partout avec HSTS, plus `X-Content-Type-Options`, la protection contre l’intégration en iframe, une politique de référent et, quand vous êtes prêt, une politique de sécurité du contenu (CSP).
- Choisissez un hébergement qui isole les sites. Chaque site avec son propre utilisateur système, un PHP à jour, le PHP bloqué dans les téléversements et un accès au serveur par clé uniquement.
La sécurité a aussi sa place dans les contrôles de lancement. Notre checklist de recette de site web couvre les tests à mener avant la mise en ligne, et la sécurité y figure aux côtés de la vitesse, de l’accessibilité et des formulaires.
Comment sécuriser un site WordPress sur le bon hébergement ?
L’hébergement détermine la part de la checklist que vous pouvez réellement appliquer. Sur un hébergement mutualisé basique, il est souvent impossible de définir des en-têtes serveur, de bloquer le PHP dans un dossier ou de consulter les journaux. Sur un hébergeur WordPress infogéré ou un serveur bien administré, c’est possible.
Posez quatre questions à un hébergeur. Chaque site est-il isolé des autres sur la même machine ? Quelles versions de PHP sont proposées, et à quelle vitesse passent-elles aux nouvelles ? Les sauvegardes sont-elles stockées hors du serveur, et pouvez-vous en restaurer une vous-même ? Y a-t-il un pare-feu et une limite des tentatives de connexion au niveau du serveur ?
Si les réponses sont floues, l’hébergeur fait partie de votre risque. Le choix de la plateforme compte aussi : notre guide pour choisir un CMS compare WordPress à d’autres options quand la sécurité et la maintenance pèsent lourd.
Quelles règles de l’UE s’appliquent à la sécurité WordPress ?
Deux lois européennes récentes sont souvent citées dans les articles sur la sécurité, et leur portée est souvent exagérée. Voici ce qu’elles disent vraiment pour un site WordPress type.
Le Cyber Resilience Act
Le Cyber Resilience Act, règlement (UE) 2024/2847, fixe des règles de sécurité pour les produits comportant des éléments numériques mis sur le marché de l’UE. Ses obligations de signalement des failles activement exploitées s’appliquent à partir du 11 septembre 2026, et la plupart des autres obligations à partir du 11 décembre 2027. Il vise les fabricants de logiciels et de produits connectés : il concerne donc surtout les entreprises qui vendent des plugins ou des thèmes. Une entreprise qui exploite simplement son propre site ne devient pas fabricant pour autant, mais elle en profitera à mesure que les plugins qu’elle achète entreront dans le cadre.
NIS2
La directive NIS2 s’applique aux moyennes et grandes organisations de secteurs listés, comme l’énergie, les transports, la santé, les infrastructures numériques et certaines industries, par le biais du droit national de chaque État membre. Si votre organisation est concernée, votre site fait partie des systèmes à protéger et vos obligations de notification d’incident vont au-delà du site. Sinon, NIS2 ne s’applique pas à votre site.
RGPD
La règle qui s’applique à presque tout le monde est le RGPD. Un site WordPress qui contient des réponses de formulaires, des comptes clients ou des commandes contient des données personnelles, et leur compromission est une violation de données personnelles. Avec un délai précis, détaillé ci-dessous.
Que faire après le piratage d’un site WordPress ?
La rapidité et l’ordre comptent plus que les outils. Suivez ces étapes si vous soupçonnez que le site a été compromis.
- Contenir. Passez le site en mode maintenance ou mettez-le hors ligne, et changez les mots de passe de chaque administrateur, du compte d’hébergement, de la base de données et de chaque service connecté.
- Préserver les preuves. Copiez les fichiers, la base de données et les journaux du serveur avant de nettoyer quoi que ce soit, pour comprendre comment l’attaquant est entré.
- Évaluer les données personnelles. Déterminez si des réponses de formulaires, des comptes ou des commandes ont été exposés. C’est ce qui fixe vos obligations légales.
- Notifier si nécessaire. Selon l’article 33 du RGPD, une violation de données personnelles doit être notifiée à l’autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle est peu susceptible d’engendrer un risque pour les personnes. Si le risque pour les personnes est élevé, elles doivent aussi être informées.
- Nettoyer ou restaurer. Restaurez une sauvegarde antérieure à l’attaque, ou réinstallez le cœur, les plugins et les thèmes depuis les sources officielles et nettoyez la base de données. Ne faites pas confiance aux fichiers présents sur le serveur pendant l’attaque.
- Fermer la porte. Trouvez et corrigez le point d’entrée, en général un plugin obsolète ou un mot de passe volé, sinon l’attaquant reviendra en quelques jours.
- Surveiller. Suivez les journaux, les modifications de fichiers et les résultats de recherche pour repérer des pages de spam dans les semaines qui suivent, et demandez un réexamen dans Google Search Console si le site a été signalé.
Consignez par écrit chaque étape et chaque décision. Le RGPD vous demande de documenter toute violation, même celle que vous n’aviez pas à notifier.
Questions fréquentes
WordPress est-il sûr pour un site d’entreprise ?
Oui, s’il est construit sobrement et maintenu. Le cœur de WordPress a une équipe sécurité dédiée et des mises à jour régulières. La plupart des piratages viennent de plugins obsolètes ou abandonnés, de mots de passe administrateur faibles et d’un hébergement médiocre. Un site avec peu de plugins bien choisis, la double authentification, un PHP à jour et des sauvegardes externalisées est une cible difficile pour les attaques automatisées qui constituent l’essentiel des menaces.
À quelle fréquence mettre à jour les plugins WordPress ?
Vérifiez les mises à jour au moins une fois par semaine et appliquez les correctifs de sécurité dès leur sortie, car les attaques commencent souvent peu après la publication d’une faille. Testez d’abord les mises à jour importantes sur une copie de préproduction. Tout plugin resté un an sans mise à jour doit être remplacé : un plugin abandonné ne recevra jamais de correctif.
Faut-il un plugin de sécurité ?
Pas toujours. Beaucoup de protections, comme la limitation des tentatives de connexion, le blocage du PHP dans les téléversements, les en-têtes de sécurité et un pare-feu, fonctionnent mieux au niveau du serveur ou de l’hébergeur, où elles arrêtent les attaques avant que WordPress ne se charge. Un plugin de sécurité peut aider sur un hébergement qui n’offre rien de tout cela, mais il ne remplace ni les mises à jour, ni des connexions robustes, ni des sauvegardes testées.
Faut-il désactiver XML-RPC dans WordPress ?
Dans la plupart des cas, oui. XML-RPC est une ancienne interface de publication à distance dont peu de sites ont encore besoin, et elle permet aux attaquants de tester de nombreux mots de passe en une seule requête. Désactivez-la au niveau du serveur ou par un simple réglage, sauf si un service dont vous dépendez, comme une ancienne application mobile de publication, en a encore besoin. Vérifiez avant de la couper.
Le Cyber Resilience Act s’applique-t-il à mon site WordPress ?
En général, pas directement. Le Cyber Resilience Act impose des obligations aux fabricants de logiciels et de produits connectés mis sur le marché de l’UE : il concerne donc surtout les entreprises qui vendent des plugins, des thèmes ou des logiciels. Une entreprise qui exploite son propre site n’est pas fabricant pour cette raison, mais elle y gagne, puisque les plugins commerciaux devront respecter les nouvelles exigences de sécurité.
Dans quel délai signaler une violation de données sur WordPress ?
Si des données personnelles ont été exposées, le RGPD vous impose de notifier la violation à votre autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle est peu susceptible de présenter un risque pour les personnes. Si le risque pour elles est élevé, vous devez aussi les informer. Documentez chaque violation, notifiée ou non.
Si votre site s’est construit plugin après plugin, ou si vous ne savez plus qui l’a mis à jour en dernier, un court audit à partir de la checklist ci-dessus est le bon point de départ ; notre guide de création de site web explique comment se prépare un site sobre dès le premier brief. Pour un site WordPress sécurisé dès sa conception, découvrez notre service de création de sites web ou parlez-nous de votre projet.
Pour aller plus loin : Next.js ou React pour un site d’entreprise, Webflow ou WordPress en 2027 : lequel convient à votre entreprise, Coût de maintenance d’un site web : ce que comprennent les contrats.
