Checklist sécurité WordPress pour les entreprises de l’UE (2026)

Cette checklist sécurité WordPress réunit les 25 mesures que nous recommandons pour tout site d’entreprise dans l’UE, réparties en six domaines : hébergement, logiciel WordPress, comptes, surveillance, sauvegardes et documentation. Suivez-la de haut en bas : les trois premiers domaines bloquent la plupart des attaques ; les trois derniers vous aident à repérer un incident, à remettre le site en état et à prouver ce que vous avez fait.

Chaque point est justifié en une phrase et renvoie, si nécessaire, vers un guide détaillé. Aucune checklist ne rend un site « sûr à 100 % », mais celle-ci vous apporte un niveau de protection que vous pouvez expliquer à un client, à un auditeur ou à une autorité de contrôle comme la CNIL.

Pourquoi la rapidité compte : l’éditeur de sécurité Patchstack a recensé 11 334 nouvelles vulnérabilités dans l’écosystème WordPress en 2025, dont 91 % dans des extensions, et constaté qu’environ la moitié des failles à fort impact avaient été exploitées dans les 24 heures (Patchstack, State of WordPress Security in 2026, un rapport d’éditeur). Une routine bien tenue vaut mieux que n’importe quel outil isolé.

Hébergement et serveur

Si le serveur est fragile, aucun réglage dans WordPress ne compensera entièrement cette faiblesse.

• HTTPS sur toutes les pages, puis HSTS. HTTPS chiffre les identifiants, les saisies de formulaires et les commandes pendant leur transit, et l’article 32, paragraphe 1, point a), du RGPD cite expressément le chiffrement. N’activez HSTS (RFC 6797) qu’une fois HTTPS opérationnel partout, en commençant par un max-age court : pendant cette durée, les navigateurs refusent toute connexion en HTTP simple.
• Une version de PHP encore maintenue. Les branches de PHP arrivées en fin de vie ne reçoivent plus de correctifs de sécurité ; comparez votre version avec la liste officielle.
• SFTP ou SSH plutôt que FTP, et un compte isolé par site. FTP transmet les mots de passe en clair et, sans isolation, un seul site piraté peut contaminer tous les autres sites hébergés sur le même compte.
• Aucune exécution de PHP dans le dossier uploads. Ce dossier ne doit contenir que des médias ; un fichier PHP qui s’y trouve est presque toujours un web shell.

Pour Apache 2.4, placez ces lignes dans wp-content/uploads/.htaccess :

<FilesMatch "\.(?i:php|phtml|phar)$">
    Require all denied
</FilesMatch>

Sous nginx, ajoutez ce bloc dans le bloc server, au-dessus de votre bloc général location ~ \.php$ (nginx applique la première location par expression régulière qui correspond) :

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Testez la configuration nginx avec nginx -t avant de la recharger. Quel que soit le serveur, vérifiez ensuite que les images s’affichent toujours et qu’un fichier .php de test placé dans uploads renvoie bien « 403 Forbidden ».

Cœur de WordPress, extensions et thèmes

C’est dans les extensions que se logent la plupart des vulnérabilités : ce domaine demande donc une routine hebdomadaire. Notre guide sur les extensions WordPress vulnérables va plus loin.

• Laissez actives les mises à jour de sécurité automatiques du cœur. Par défaut, WordPress installe en arrière-plan les versions mineures, qui contiennent les correctifs de sécurité. Vérifiez qu’aucun réglage ni outil de votre hébergeur ne les a désactivées.
• Mettez à jour extensions et thèmes en quelques jours, pas en quelques mois. Pour les vulnérabilités les plus exploitées, Patchstack a mesuré un délai médian pondéré de cinq heures avant l’exploitation de masse. Les mises à jour automatiques, disponibles depuis WordPress 5.5, réduisent cet écart pour les extensions à faible risque.
• Supprimez ce que vous n’utilisez pas. Les fichiers d’une extension désactivée restent sur le serveur et peuvent toujours être exploités ; wp plugin list --status=inactive dresse la liste des candidates.
• Remplacez les extensions abandonnées et n’utilisez jamais de copies « nulled ». Dans les données de Patchstack, 46 % des vulnérabilités n’avaient aucun correctif au moment de leur divulgation. Une extension abandonnée risque de ne jamais en recevoir, et une copie piratée ne reçoit aucune mise à jour.
• Désactivez l’éditeur de fichiers du tableau de bord. define( 'DISALLOW_FILE_EDIT', true ); dans wp-config.php supprime les éditeurs de fichiers des thèmes et des extensions : un identifiant administrateur volé ne suffit plus pour coller du code dans un fichier de thème.

Comptes et connexions

Un administrateur peut installer des extensions, autrement dit exécuter du code sur votre serveur. Les rôles par défaut (Administrateur, Éditeur, Auteur, Contributeur, Abonné) permettent d’appliquer facilement le principe du moindre privilège.

• Des mots de passe uniques et l’authentification à deux facteurs pour chaque Administrateur et Éditeur. Les attaques par bourrage d’identifiants (credential stuffing) testent justement les mots de passe divulgués et réutilisés. Le cœur de WordPress n’intègre pas de 2FA ; notre guide de l’authentification à deux facteurs présente les options.
• Un compte personnel par personne, avec le rôle le plus bas qui suffit. Les identifiants « agence » partagés masquent qui a fait quoi et ne peuvent pas être révoqués proprement.
• Supprimez les anciens comptes et les mots de passe d’application inutilisés. Les anciens salariés et les agences gardent leur accès tant que personne ne le supprime ; les mots de passe d’application (depuis WordPress 5.6) figurent sur le profil de chaque utilisateur.
• Limitez les tentatives de connexion et désactivez XML-RPC si rien ne l’utilise. XML-RPC est activé par défaut et accepte des mots de passe en dehors du formulaire de connexion habituel. Vérifiez d’abord qu’aucune extension ni application n’en dépend encore.

Surveillance et détection

Vous ne pourrez respecter un délai de notification de 72 heures que si vous remarquez la violation.

• Des analyses programmées : logiciels malveillants et intégrité des fichiers. De nouveaux fichiers PHP dans uploads, des fichiers du cœur modifiés et du code obfusqué sont des traces typiques d’une compromission. wp core verify-checksums compare les fichiers du cœur avec les sommes de contrôle officielles de WordPress.org. Voir les 12 signes que votre site a été piraté.
• Journaux d’activité et alertes à la création d’un administrateur. Les comptes administrateurs cachés sont un moyen courant pour les attaquants de conserver leur accès. Les journaux aident à reconstituer un incident ; fixez une durée de conservation, car ils contiennent des adresses IP.
• Des alertes de vulnérabilité pour les extensions que vous utilisez réellement. Une base de données de vulnérabilités, par exemple celle de WPScan ou de Patchstack, vous prévient lorsqu’une de vos extensions présente un problème connu.
• Google Search Console et surveillance de disponibilité. Search Console signale les problèmes de sécurité que Google détecte sur votre site, comme du spam injecté ; la surveillance de disponibilité repère les pannes.

L’extension Security Audit & Compliance de secaudit.eu automatise plusieurs de ces contrôles : intégrité des fichiers, signatures de logiciels malveillants, administrateurs cachés, extensions obsolètes, mots de passe faibles et réglages de durcissement. Elle rattache ses constats à l’article 32 du RGPD et à l’article 21 de NIS2.

Sauvegardes et restauration

L’article 32, paragraphe 1, point c), du RGPD exige la capacité de rétablir la disponibilité des données personnelles et l’accès à celles-ci dans des délais appropriés après un incident. Seules des sauvegardes testées tiennent cette promesse.

• Des sauvegardes automatiques des fichiers et de la base de données, au moins quotidiennes pour un site actif. Commandes et saisies de formulaires changent chaque jour ; une sauvegarde vieille d’une semaine les perd.
• Au moins une copie hors du serveur et hors d’atteinte. Une archive de sauvegarde placée à la racine web peut être téléchargée par quiconque devine son nom, et une sauvegarde que le site peut supprimer, un attaquant peut la supprimer aussi.
• Testez une restauration au moins deux fois par an. Une sauvegarde jamais restaurée est un espoir, pas un plan, et l’article 32, paragraphe 1, point d), vous demande de tester régulièrement vos mesures.
• Un plan d’incident tenant sur une page. Qui décide, qui appelle l’hébergeur, où se trouvent les sauvegardes saines et comment notifier une violation de données sous 72 heures. Notre plan de suppression des logiciels malveillants couvre le nettoyage.

Documentation et conformité

L’article 5, paragraphe 2, du RGPD vous oblige à pouvoir démontrer vos mesures. Des traces courtes et datées suffisent.

• Un inventaire des extensions, des thèmes, des services externes et des accès. On ne peut ni corriger ni contrôler ce que l’on ne connaît pas. Les requêtes vers des tiers, comme les Google Fonts chargées depuis les serveurs de Google, ont aussi leur place dans cette liste.
• Des contrats de sous-traitance avec votre hébergeur et votre agence. Toute personne qui traite des données personnelles pour votre compte, y compris une agence disposant d’un accès administrateur, doit en signer un au titre de l’article 28 du RGPD.
• Un registre des violations et des incidents. L’article 33, paragraphe 5, vous impose de documenter chaque violation de données personnelles, y compris celles que vous n’aviez pas à notifier.
• Des preuves datées, revues au moins une fois par an. Journaux de mises à jour, rapports d’analyse et tests de restauration montrent que vos mesures fonctionnent réellement.

Checklist sécurité WordPress : correspondance avec le RGPD et NIS2

L’article 32, paragraphe 1, du RGPD exige des mesures techniques et organisationnelles appropriées, compte tenu de l’état des connaissances, des coûts et du risque. L’article 21, paragraphe 2, de la directive NIS 2 énumère dix mesures minimales pour les entités qui relèvent de son champ d’application.

NIS2 vise principalement les moyennes et grandes entreprises des secteurs listés, et les modalités varient d’un pays à l’autre : vérifiez la loi NIS2 nationale de votre pays. Les petits fournisseurs sont touchés indirectement, car les entités concernées doivent gérer la sécurité de leur chaîne d’approvisionnement et réclament des preuves. Voir nos articles sur l’article 32 du RGPD et sur le champ d’application de NIS2. Si vous vendez des extensions ou des thèmes, le Cyber Resilience Act (CRA, règlement sur la cyberrésilience) ajoute des obligations de fabricant.

FAQ

À quelle fréquence faut-il repasser cette checklist ?

Nous recommandons un passage complet au moins une fois par an, ainsi qu’après tout changement important, comme un nouvel hébergeur ou une nouvelle agence.

Appliquer la checklist rend-il mon site conforme au RGPD ?

Aucune checklist n’y parvient à elle seule. L’article 32 repose sur une approche par les risques : une boutique avec des comptes clients exige davantage qu’un site vitrine. La checklist couvre le socle technique ; votre documentation explique pourquoi il correspond à votre niveau de risque.

Nous n’avons qu’un petit site vitrine. Sommes-nous concernés ?

Pour l’essentiel, oui. Les attaques automatisées ignorent la taille de l’entreprise, et le RGPD s’applique dès qu’un formulaire de contact collecte des données personnelles.

Cet article est une information générale et ne constitue pas un conseil juridique.