Sécuriser WordPress : la checklist priorisée en 15 mesures (2026)

L’essentiel en une minute

Pour sécuriser WordPress, la priorité n’est pas l’extension de sécurité : ce sont les extensions tout court. Selon le rapport annuel de Patchstack, 91 % des nouvelles vulnérabilités recensées en 2025 dans l’écosystème WordPress se trouvaient dans des extensions, et seulement 6 dans le cœur du logiciel. Le travail utile porte donc sur ce que vous installez, sur les comptes qui peuvent l’administrer et sur votre capacité à revenir en arrière.

Ce guide de sécurité WordPress classe 15 mesures par risque couvert et par effort. Les extraits de code viennent de la documentation officielle, consultée les 1er et 2 novembre 2026, avec les précautions qui évitent de casser le site. C’est une synthèse de sources publiques : nous n’avons testé aucun réglage sur un site en production.

Points clés

• Patchstack, un éditeur de solutions de sécurité, a recensé 11 334 nouvelles vulnérabilités WordPress en 2025 : 91 % dans des extensions, 9 % dans des thèmes, 6 dans le cœur.
• Selon le même éditeur, 46 % de ces failles n’avaient pas de correctif au moment de leur divulgation : supprimer une extension inutile protège mieux que d’attendre.
• WordPress n’intègre pas la double authentification : la documentation officielle renvoie vers une extension ou un fournisseur d’identité.
• Chaque réglage de serveur se teste d’abord sur une copie, avec un accès SFTP ou SSH prêt pour revenir en arrière.
• Une sauvegarde n’existe que si sa restauration a été testée. L’ANSSI recommande la règle 3-2-1, avec une copie hors ligne.

---

D’où viennent vraiment les failles WordPress

Le cœur de WordPress est rarement en cause ; l’écosystème qui l’entoure l’est presque toujours. Le rapport « State of WordPress Security in 2026 » de Patchstack (page mise à jour le 25 février 2026) compte 11 334 nouvelles vulnérabilités en 2025, soit 42 % de plus qu’en 2024. Il en situe 91 % dans des extensions et 9 % dans des thèmes, avec seulement 6 failles dans le cœur, toutes de faible priorité.

Ces chiffres viennent d’un éditeur qui vend une protection contre ces failles et ne couvrent que celles qu’il a recensées. La cible est vaste : selon W3Techs, WordPress équipe 39,5 % de l’ensemble des sites web au 2 novembre 2026.

Le même rapport explique pourquoi la mise à jour seule ne suffit pas. Selon Patchstack, 46 % des failles n’avaient pas reçu de correctif du développeur au moment de leur divulgation publique. 36 % (4 124) étaient assez graves pour justifier une règle de protection, et 17 % (1 966) présentaient une gravité élevée, propice aux attaques automatisées de masse.

Les composants payants ne sont pas plus sûrs. Sur une autre base, celle des signalements reçus, Patchstack compte 1 983 signalements valides visant des extensions ou thèmes premium ou freemium, soit 29 % des signalements, et en juge 76 % exploitables. Le délai d’attaque est court : environ la moitié des failles à fort impact ont été exploitées dans les 24 heures, et pour les plus ciblées, la médiane pondérée par l’intensité des attaques est de 5 heures. Notre panorama des cyberattaques les plus fréquentes situe ces menaces dans le contexte général.

---

Sécuriser WordPress : le tableau des priorités

Commencez par le haut : les premières lignes couvrent les risques les plus fréquents pour un effort faible. Le classement est le nôtre, fondé sur les sources citées dans chaque section.

Où coller les extraits. Les constantes se placent dans wp-config.php, au-dessus de la ligne « That’s all, stop editing! », comme dans les exemples de la page officielle ; si la constante existe déjà, par exemple WP_DEBUG, modifiez la ligne existante au lieu d’en ajouter une seconde. Les filtres PHP vont dans une extension « must-use » du dossier wp-content/mu-plugins, chargée automatiquement, ou dans un thème enfant. Gardez toujours un accès SFTP ou SSH pour retirer une ligne qui bloque le site.

---

1. Les mises à jour, sans exception

Mettre à jour reste la première mesure pour sécuriser WordPress, à condition de l’automatiser. Le manuel officiel « Hardening WordPress » rappelle que les mises à jour automatiques existent depuis la version 3.7.

Pour le cœur, la page officielle Editing wp-config.php indique que les mises à jour mineures, celles de maintenance et de sécurité, sont appliquées par défaut. Pour les versions majeures, l’écran Tableau de bord, puis Mises à jour, propose un lien pour les automatiser. La constante WP_AUTO_UPDATE_CORE fait la même chose depuis wp-config.php :

define( 'WP_AUTO_UPDATE_CORE', true );

La valeur 'minor' correspond au réglage par défaut ; false coupe toutes les mises à jour du cœur. D’après le code de l’écran des mises à jour, dès que cette constante est définie, elle prend le pas sur le réglage de l’interface, qui n’est plus modifiable.

Pour les extensions et les thèmes, la documentation Plugin and themes auto-updates précise que depuis WordPress 5.5, l’administrateur les active extension par extension, dans une colonne dédiée de l’écran Extensions, et thème par thème. La même page suggère de s’assurer, avant de les activer, qu’un retour en arrière est possible. Face à des exploitations qui démarrent en quelques heures, une mise à jour manuelle hebdomadaire arrive souvent trop tard.

---

2. Moins d’extensions, de meilleures sources

Chaque extension active est du code tiers exécuté sur votre serveur. Le manuel officiel demande de garder les extensions à jour, de supprimer celles que vous n’utilisez pas et de ne les obtenir que de sources fiables, comme le répertoire WordPress.org ou des sociétés reconnues.

Désactiver ne suffit pas : supprimez. Face à une faille que son auteur ne corrige pas, une extension désinstallée reste la protection la plus sûre. Avant d’installer, vérifiez la date de dernière mise à jour sur la page du répertoire, et n’utilisez jamais une copie « nulled » d’une extension premium. Le même raisonnement vaut pour les thèmes inutilisés.

---

3. Des comptes administrateurs solides

Un compte administrateur compromis donne tout le site. La page officielle Brute Force Attacks recommande de ne pas utiliser l’identifiant « admin », de limiter le nombre d’administrateurs et d’appliquer le moindre privilège au quotidien, par exemple avec un compte Éditeur pour publier.

Côté mots de passe, le manuel « Hardening WordPress » écarte les mots du dictionnaire, les mots de passe courts et ceux qui reprennent votre nom ou celui du site. Un gestionnaire évite en plus la réutilisation : notre comparatif de gestionnaire de mot de passe gratuit aide à en choisir un.

Supprimez aussi les comptes d’anciens prestataires et de test : le phishing vise précisément les identifiants d’administration.

---

4. Double authentification et tentatives de connexion

Avec la double authentification, un mot de passe volé ne suffit plus à lui seul pour se connecter, mais WordPress ne l’intègre pas. La page officielle Brute Force Attacks le dit explicitement : activez la 2FA pour tous les administrateurs, via une extension ou votre fournisseur d’identité, car le cœur de WordPress ne l’inclut pas.

L’extension Two Factor, publiée par le compte WordPress.org, propose une application d’authentification (TOTP), des codes par e-mail et des codes de secours. Préférez l’application : un code par e-mail relève de la validation en deux étapes selon la CNIL, comme l’explique notre guide de la double authentification. Générez et rangez les codes de secours avant tout, pour ne pas vous enfermer dehors si le téléphone est perdu.

Pour la force brute, la même page recommande de limiter les tentatives de préférence en amont (pare-feu, CDN ou serveur web), car une extension s’exécute dans PHP et consomme des ressources pendant une attaque. Son exemple Nginx :

# Define a shared zone for rate limiting
limit_req_zone $binary_remote_addr zone=logins:10m rate=10r/m;

server {
    # ...

    location = /wp-login.php {
        limit_req zone=logins burst=20 nodelay;
        include fastcgi_params;
        # pass to PHP-FPM or upstream as usual
    }

    location = /xmlrpc.php {
        limit_req zone=logins burst=20 nodelay;
        include fastcgi_params;
        # pass to PHP-FPM or upstream as usual
    }
}

Ne le collez pas tel quel. Selon la documentation de Nginx, une location exacte (=) arrête la recherche : ces deux blocs doivent donc reprendre vos directives PHP habituelles (fastcgi_pass, SCRIPT_FILENAME), à la place du commentaire, sinon la connexion casse. Derrière un CDN ou un proxy, $binary_remote_addr vaut l’adresse du proxy : configurez d’abord le module realip. Vérifiez avec nginx -t avant de recharger, et testez sur une copie, comme le demande la page officielle.

Le fichier xmlrpc.php, cible fréquente, se désactive si vous ne l’utilisez pas ; sinon, restreignez-le, car Jetpack ou les applications mobiles peuvent en dépendre.

---

5. L’API REST, les auteurs et les mots de passe d’application

L’API REST est active par défaut, et c’est voulu : la FAQ officielle de l’API REST déconseille de la désactiver, car l’administration de WordPress en dépend. Mieux vaut savoir ce qu’elle expose et le restreindre.

Le cas classique est l’énumération des utilisateurs. La référence de l’endpoint Users montre qu’une requête sur /wp-json/wp/v2/users dans le contexte public view renvoie notamment l’identifiant numérique, le nom affiché, le slug et le lien de la page auteur. L’identifiant de connexion et l’adresse e-mail ne sont exposés que dans le contexte edit. D’après le code du contrôleur, un visiteur anonyme ne voit que les auteurs qui ont publié des contenus.

Or le code de wp_insert_user() construit par défaut ce slug à partir de l’identifiant de connexion : la liste publique livre donc souvent la moitié du couple identifiant et mot de passe. Les pages auteurs font de même : selon le code de redirect_canonical(), une adresse /?author=1 redirige vers /author/<slug>/ si l’auteur a publié.

Deux façons de limiter l’exposition :

• Publier avec un compte distinct du compte d’administration. Cela couvre l’API comme les pages auteurs. Pour un compte existant, la commande WP-CLI wp user update accepte l’option --user_nicename, qui change ce slug. Réattribuez aussi à ce compte les contenus déjà publiés par l’administrateur, sinon celui-ci reste visible ; les liens vers l’ancienne page auteur cesseront alors de fonctionner.
• Exiger l’authentification pour toute l’API, avec le filtre ci-dessous, documenté par la FAQ officielle.

add_filter( 'rest_authentication_errors', function( $result ) {
    // If a previous authentication check was applied,
    // pass that result along without modification.
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }

    // No authentication has been performed yet.
    // Return an error if user is not logged in.
    if ( ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_not_logged_in',
            __( 'You are not currently logged in.' ),
            array( 'status' => 401 )
        );
    }

    // Our custom authentication check should have no effect
    // on logged-in requests
    return $result;
});

Ce filtre coupe aussi l’accès anonyme aux articles via l’API : un site « headless » ou une extension qui lit vos contenus sans compte cesserait de fonctionner. Testez-le d’abord sur une copie.

Les mots de passe d’application, présents depuis WordPress 5.6 selon la page Authentication, servent aux intégrations. Le guide d’intégration officiel indique qu’ils sont disponibles par défaut sur les sites en HTTPS et révocables depuis l’écran de l’utilisateur. Ce filtre les coupe entièrement, ce qui casse les intégrations qui en dépendent :

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Le filtre wp_is_application_passwords_available_for_user permet plutôt de les réserver aux administrateurs, selon le même guide.

---

6. Durcir wp-config.php et les permissions

Le fichier wp-config.php contient les accès à la base de données. Les constantes ci-dessous viennent de la page officielle Editing wp-config.php et du manuel Hardening WordPress. Copiez le fichier avant toute modification.

Désactiver l’éditeur de fichiers. Avec un compte administrateur volé, l’éditeur intégré permet d’injecter du code PHP :

define( 'DISALLOW_FILE_EDIT', true );

Le manuel précise que cette ligne n’empêche pas l’envoi de fichiers malveillants, mais peut arrêter certaines attaques. La constante DISALLOW_FILE_MODS va plus loin : elle bloque l’installation et la mise à jour des extensions et des thèmes depuis l’administration. Attention : selon le code de WP_Automatic_Updater::is_disabled(), elle désactive aussi toutes les mises à jour automatiques, y compris les correctifs de sécurité du cœur. Réservez-la aux sites dont les mises à jour passent par un déploiement régulier.

Clés et salages uniques. Les huit constantes AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs équivalents _SALT doivent être longues et aléatoires. La documentation de wp-config.php renvoie vers le générateur officiel et précise qu’on peut les changer à tout moment pour invalider tous les cookies existants : tous les utilisateurs devront se reconnecter. Remplacez les huit lignes existantes, sans les dupliquer.

Débogage coupé en production. Afficher les erreurs PHP révèle des chemins et des versions. Configuration de production de la page officielle, qui remplace les lignes WP_DEBUG existantes :

@ini_set( 'log_errors', 'On' );
@ini_set( 'display_errors', 'Off' );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false ); // 5.2 and later
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

HTTPS pour l’administration. La constante FORCE_SSL_ADMIN force les connexions et l’administration en HTTPS. Elle est superflue si l’adresse du site est déjà en https://. Derrière un proxy ou un CDN qui termine le HTTPS, la page officielle HTTPS prévient qu’elle provoque une boucle de redirection infinie, et donne ce correctif, qui suppose un proxy configuré pour transmettre l’en-tête X-Forwarded-Proto :

define( 'FORCE_SSL_ADMIN', true );
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false )
    $_SERVER['HTTPS'] = 'on';

N’utilisez ce correctif que si le serveur n’est joignable qu’à travers ce proxy, car n’importe quel client peut envoyer cet en-tête. En cas de boucle, retirez la constante par SFTP.

Permissions de fichiers. Le manuel Hardening WordPress recommande 755 pour les dossiers et 644 pour les fichiers, avec ces commandes à adapter à votre chemin d’installation :

find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;
find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Ces commandes ne changent pas le propriétaire : vérifiez d’abord sous quel utilisateur tourne PHP et à qui appartiennent les fichiers, sinon les mises à jour peuvent échouer. Pour wp-config.php, le manuel demande que seuls vous et le serveur web puissiez le lire, « ce qui signifie généralement 400 ou 440 » (notre traduction). Appliquez ce réglage après les commandes find, et seulement si PHP s’exécute sous le propriétaire du fichier (400) ou dans son groupe (440) : sinon PHP ne peut plus lire le fichier et le site tombe. Sur un hébergement mutualisé, demandez à l’hébergeur.

Notre guide des commandes Linux de base explique chmod et find. Le manuel recommande aussi SFTP plutôt que FTP.

---

7. HTTPS et en-têtes de sécurité

HTTPS est le minimum : il chiffre les échanges, dont les cookies de session. Les en-têtes de sécurité ajoutent une protection côté navigateur. Le tableau part de l’aide-mémoire HTTP Headers de l’OWASP, consulté le 2 novembre 2026, avec deux adaptations pour WordPress signalées comme telles :

Pour X-Frame-Options, l’OWASP propose DENY, mais l’outil de personnalisation de WordPress affiche le site dans un cadre de même origine. WordPress envoie d’ailleurs lui-même SAMEORIGIN sur l’administration et la page de connexion, d’après le code de send_frame_options_header().

Pour HSTS, l’OWASP avertit qu’un réglage trop long ou un problème de certificat peut bloquer des visiteurs légitimes. Augmentez max-age par paliers ; includeSubDomains exige que tous les sous-domaines soient en HTTPS, et preload vient en dernier, car il est difficile à annuler. Une politique CSP stricte casse souvent l’éditeur de blocs : déployez-la d’abord avec l’en-tête Content-Security-Policy-Report-Only.

Sur Nginx, la documentation du module headers précise qu’un bloc contenant ses propres add_header n’hérite plus de ceux du niveau supérieur. Notre tutoriel Nginx reverse proxy avec Docker Compose montre où placer ces directives dans une configuration HTTPS.

---

8. Sauvegardes 3-2-1 et tests de restauration

La sauvegarde est la seule mesure qui répare au lieu de prévenir. Le guide Sauvegarde des systèmes d’information de l’ANSSI (version du 27 novembre 2025) recommande la règle 3-2-1 : 3 copies distinctes des données, c’est-à-dire la production et 2 sauvegardes sur des supports différents, dont 1 hors ligne.

Notre adaptation pour un site WordPress :

• Trois éléments ensemble : la base de données, wp-content et wp-config.php.
• Une copie hors du serveur, chez un autre fournisseur que l’hébergeur.
• Une copie hors ligne, au sens de l’ANSSI, qu’un attaquant présent sur le serveur ne peut pas effacer.

Cybermalveillance.gouv.fr insiste sur le test : sauvegardez le site, sa configuration et ses bases de données, puis testez la restauration.

Nous conseillons un test par trimestre sur une copie de préproduction. Le choix de l’hébergeur compte aussi ; notre guide de l’hébergement cloud pour développeurs compare les offres.

---

9. Pare-feu applicatif, CDN et surveillance

Un pare-feu applicatif (WAF) filtre les requêtes malveillantes avant qu’elles n’atteignent WordPress. La page officielle Brute Force Attacks cite Cloudflare, Sucuri ou le pare-feu de l’hébergeur.

Selon la documentation de Cloudflare, un jeu de règles gérées gratuit est disponible sur toutes les offres, tandis que le jeu complet et celui de l’OWASP sont réservés aux offres payantes. Le pare-feu de Sucuri est un service payant activé en modifiant les DNS. Les hébergeurs proposent souvent un module comme ModSecurity, que le manuel officiel mentionne.

Ne surestimez pas ces outils. Patchstack, qui vend sa propre protection, rapporte deux tests d’intrusion menés en 2025 chez des hébergeurs : les défenses classiques n’ont bloqué que 12 % des attaques visant des failles propres à WordPress, puis 26 % dans un test plus large.

Côté surveillance, le manuel Hardening WordPress conseille de garder les journaux et de surveiller les modifications de fichiers, par exemple avec Git, inotify ou OSSEC. Un nouveau fichier .php dans wp-content/uploads doit déclencher une alerte.

---

Quelle extension de sécurité choisir

Une extension de sécurité WordPress regroupe plusieurs mesures de ce guide, sans remplacer les mises à jour ni les sauvegardes. Données relevées le 2 novembre 2026 sur les pages officielles de WordPress.org, classées par installations actives. Aucun lien n’est affilié.

Selon le journal des modifications de l’extension (adresse better-wp-security), la version 10.0.0 renomme Solid Security, ex-iThemes Security, en Kadence Security. Le nombre d’installations mesure la popularité, pas la qualité.

Notre conseil, sans classement : une seule extension de sécurité complète, pour éviter les conflits, ou une approche minimale qui combine Two Factor, une limitation des connexions en amont et un WAF.

---

Site piraté : que faire

Si votre site est défiguré ou redirige vers des pages inconnues, suivez la fiche réflexe « Défiguration de site Internet, que faire ? » de Cybermalveillance.gouv.fr (mise à jour le 28 octobre 2026). Ses étapes, résumées :

1. Isoler la machine touchée d’Internet, ou demander à l’hébergeur de le faire, sans l’éteindre : la fiche demande ensuite une copie de sa mémoire.

2. Conserver les preuves : journaux et captures d’écran.

3. Faire une copie complète de la machine et de sa mémoire, avant toute réparation.

4. Notifier la CNIL si des données personnelles sont touchées et que la violation présente un risque (voir plus bas).

5. Identifier le point d’entrée : selon la fiche, le plus souvent un mot de passe d’administration faible, un défaut de configuration ou une faille connue non corrigée.

6. Déposer plainte auprès de la police, de la gendarmerie ou par écrit au procureur.

7. Corriger les failles et changer tous les mots de passe avant la remise en ligne.

8. Contacter l’hébergeur, puis se faire assister au besoin par un professionnel.

Pour le diagnostic et l’orientation, le service officiel 17Cyber, proposé par la police, la gendarmerie et Cybermalveillance.gouv.fr, guide les victimes. Côté WordPress, l’étape 7 inclut de régénérer les clés et salages pour déconnecter toutes les sessions et de révoquer les mots de passe d’application.

Le RGPD ajoute une obligation. Selon l’article 33 du RGPD, le responsable du traitement notifie la violation à la CNIL dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes. Un prestataire sous-traitant prévient son client dans les meilleurs délais.

Selon la page de notification de la CNIL, un risque élevé impose aussi d’informer les personnes concernées, et l’incident doit toujours être documenté en interne. Une défiguration qui entraîne une fuite, une altération ou une indisponibilité des données est une violation, rappelle la fiche de Cybermalveillance.gouv.fr.

---

Ce que nous n’avons pas pu vérifier

Plusieurs points restent incertains ou hors de portée de cette synthèse :

• D’autres jeux de données que celui de Patchstack. Les rapports de Wordfence n’ont pas pu être lus au moment de la rédaction ; la page de Patchstack ne détaille pas sa méthode de comptage.
• L’effet réel de chaque mesure. Aucun réglage n’a été testé sur un site en production. Les extraits sont recopiés de la documentation officielle et doivent être testés en préproduction.
• La couverture du pare-feu gratuit de Cloudflare face aux failles propres à WordPress : la documentation consultée ne la détaille pas.

---

Questions fréquentes

Une extension de sécurité suffit-elle ?

Non. Elle ne remplace ni les mises à jour, ni la suppression des extensions inutiles, ni des sauvegardes testées. La documentation officielle recommande aussi de bloquer les attaques en amont quand c’est possible.

Faut-il désactiver l’API REST de WordPress ?

Non. La FAQ officielle de l’API REST explique que la désactiver casse des fonctions de l’administration. Elle propose plutôt d’exiger une authentification avec le filtre rest_authentication_errors, à réserver aux sites qui n’exposent pas de contenu public par l’API.

DISALLOW_FILE_MODS est-il recommandé ?

Seulement si vos mises à jour passent par un déploiement. Selon le code de WP_Automatic_Updater::is_disabled(), cette constante désactive aussi les mises à jour automatiques de sécurité. Pour la plupart des sites, DISALLOW_FILE_EDIT suffit.

Comment sécuriser WordPress sans compétences techniques ?

Commencez par cinq mesures accessibles depuis l’administration : mises à jour automatiques, suppression des extensions inutiles, double authentification, gestionnaire de mots de passe et sauvegardes hors du serveur. Confiez ensuite wp-config.php, les permissions et les en-têtes à votre hébergeur ou à un prestataire.

---

À propos de l’auteur

Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d’IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur.

Méthode. Synthèse fondée exclusivement sur des sources publiques consultées les 1er et 2 novembre 2026 : manuels officiels de WordPress (Advanced Administration, REST API, référence du code, WP-CLI), pages des extensions sur WordPress.org, rapport de Patchstack, documentation de Nginx, de Cloudflare et de Sucuri, aide-mémoire de l’OWASP, guide de l’ANSSI, publications de Cybermalveillance.gouv.fr et de la CNIL. Les chiffres de Patchstack sont des données d’éditeur, signalées comme telles. Les citations issues de sources en anglais sont traduites par nos soins. Aucun test n’a été mené, aucun lien n’est affilié et aucune relation commerciale ne lie l’auteur aux éditeurs mentionnés.

Une erreur ou un réglage qui a changé ? Écrivez à [email protected] : l’article sera corrigé et la date de mise à jour modifiée.

Dernière mise à jour : 2 novembre 2026.

Image : Brett Sayles via Pexels (Pexels License).