Sécuriser WordPress : le guide d’un développeur senior

Pour sécuriser WordPress, l’essentiel tient en trois gestes : tenir à jour le cœur, les extensions et le thème (après un test en préproduction), protéger les comptes (mots de passe uniques, double authentification, droits limités) et fermer ce qui ne sert pas (éditeur de fichiers, XML-RPC, PHP dans les médias). Viennent ensuite un pare-feu applicatif, des en-têtes de sécurité HTTP, des sauvegardes hors du serveur réellement testées et une surveillance continue.

Je développe et maintiens des sites WordPress depuis 14 ans. Ce guide suit l’ordre dans lequel j’applique ces mesures, avec le code exact, les fausses bonnes idées à éviter et une checklist d’audit.

Par où les sites WordPress sont réellement attaqués

La plupart des attaques ne visent personne en particulier. Des robots testent partout les mêmes portes : une version d’extension vulnérable, un mot de passe faible ou déjà divulgué, un fichier xmlrpc.php ouvert aux essais de mots de passe, un thème « nulled » (premium piraté) livré avec une porte dérobée.

Le cœur de WordPress est rarement en cause : une équipe sécurité dédiée le suit et ses correctifs s’installent automatiquement. Les failles exploitées viennent surtout des extensions et des thèmes, puis des comptes mal protégés. L’attaque « sophistiquée » est avant tout industrialisée : elle réussit sur les sites en retard.

Le vrai ordre de priorité

Voici l’ordre dans lequel j’applique les mesures. C’est aussi le plan de ce guide :

1. Mises à jour encadrées : cœur, extensions, thème et PHP, testés avant la mise en ligne.
2. Comptes : moindre privilège, double authentification, limitation des tentatives.
3. Configuration durcie : wp-config.php, droits des fichiers, XML-RPC, API REST.
4. Pare-feu applicatif, pour filtrer les attaques avant le code vulnérable.
5. HTTPS et en-têtes de sécurité, pour limiter l’exploitation de certaines failles.
6. Sauvegardes hors du serveur, avec une restauration testée.
7. Surveillance, pour réagir vite et comprendre ce qui s’est passé.

Mettre à jour sans casser : la première ligne de défense

En octobre 2026, la version courante est WordPress 7.1.3. Seule la dernière version est officiellement maintenue : l’équipe sécurité rétroporte ses correctifs vers les anciennes branches « par courtoisie » (la 7.0 en est à 7.0.7), comme l’explique la page sécurité de WordPress.org, mais cela ne remplace pas la mise à niveau. Pour un exemple concret, lisez mon analyse de la faille corrigée en urgence par WordPress 7.0.2, puis ce qu’il faut vérifier avant de passer à WordPress 7.1.

Quelles mises à jour automatiques activer ?

Les versions mineures du cœur, qui portent les correctifs de sécurité, s’installent automatiquement : gardez ce réglage. Sur un site installé depuis WordPress 5.6, les versions majeures aussi ; la constante WP_AUTO_UPDATE_CORE (voir wp-config.php plus bas) les fait passer par la préproduction. Pour les extensions, réservez la mise à jour automatique à celles dont une régression ne bloque pas le site, comme l’extension de sécurité. Paiement, constructeur de pages (Avada, Elementor) ou extension qui modifie la base de données passent d’abord par la préproduction. Ce filtre fixe la règle dans le code, sans bloquer les mises à jour de sécurité que WordPress.org impose parfois :

// À ajouter au mu-plugin de durcissement (plus bas) : mise à jour automatique
// réservée à quelques extensions, les autres passent par la préproduction.
add_filter(
	'auto_update_plugin',
	static function ( $update, $item ) {
		$auto = array( 'wordfence' );
		if ( isset( $item->slug ) && in_array( $item->slug, $auto, true ) ) {
			return true;
		}
		// Les autres : seulement les mises à jour de sécurité forcées par WordPress.org.
		return ! empty( $item->autoupdate );
	},
	10,
	2
);

Tester en préproduction avant la mise en ligne

La mise à jour est la meilleure protection d’un site WordPress et la première cause de ses pannes. Ma méthode : sauvegarde complète, mises à jour appliquées sur une copie de préproduction, vérification des pages clés, des formulaires et du tunnel de commande, puis déploiement. Un correctif de sécurité critique passe en priorité. C’est la méthode que j’applique dans la maintenance des sites WordPress que je suis, avec WP Umbrella pour piloter mises à jour et sauvegardes.

Supprimer les extensions abandonnées et inutiles

Une extension désactivée garde ses fichiers sur le serveur, et ils restent souvent appelables directement : ce qui ne sert pas se supprime. Sur la fiche wordpress.org, surveillez la date de dernière mise à jour et la version de WordPress testée ; une extension fermée ou figée depuis plus d’un an doit être remplacée. Wordfence signale celles qui ont une vulnérabilité connue ou qui ont été abandonnées. Et jamais de version « nulled » : c’est installer soi-même une porte dérobée.

Une version de PHP encore maintenue

WordPress 7.1 accepte encore PHP 7.4, mais WordPress.org recommande PHP 8.3 ou plus. D’après le calendrier de php.net, PHP 8.1 et les versions antérieures ne reçoivent plus de correctifs de sécurité, et PHP 8.2 n’en recevra plus après le 31 décembre 2026. Visez PHP 8.3 ou 8.4, après un test en préproduction. Un hébergement infogéré tient ces versions à jour pour vous.

Comptes et authentification : fermer la porte la plus visée

La page de connexion est la cible la plus testée d’un site WordPress, et un compte administrateur volé donne tout : extensions, code, nouveaux comptes.

Moindre privilège et ménage des comptes

Un compte nominatif par personne, avec le rôle le plus bas possible : Éditeur pour les contenus, Auteur pour ses propres articles, Gestionnaire de boutique sur WooCommerce. Les comptes d’anciens prestataires ou de test sont supprimés. À la reprise d’un site, l’audit commence par cette liste :

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Supprimer un compte inutile en attribuant ses contenus à un autre utilisateur (ici l'ID 2)
wp user delete 7 --reassign=2

Pour vous débarrasser d’un compte « admin », créez un administrateur nominatif, puis supprimez l’ancien en réattribuant ses contenus, plutôt que de le renommer par une requête SQL.

Mots de passe et double authentification (2FA)

Un mot de passe long et unique, stocké dans un gestionnaire, reste la base. Depuis WordPress 6.8, le cœur hache les mots de passe avec bcrypt : une base volée est plus dure à exploiter, mais un mot de passe faible ou réutilisé reste vulnérable.

La 2FA est indispensable pour tout compte à privilèges. La méthode courante est le code à six chiffres d’une application (TOTP) comme Google Authenticator, Authy ou 1Password, avec des codes de secours gardés hors du site. Le cœur ne la propose pas ; trois extensions maintenues et testées avec WordPress 7.1.3 :

• Two Factor, publiée par WordPress.org : application TOTP, codes par e-mail, codes de secours ;
• Wordfence : 2FA, passkeys, et blocage des administrateurs dont le mot de passe figure dans une fuite connue ;
• WP 2FA (Melapress), pratique pour imposer la 2FA à certains rôles.

« Google Authenticator » désigne ici l’application du téléphone, pas l’extension homonyme. Quant à Duo Two-Factor Authentication, elle n’est plus testée avec les versions récentes de WordPress.

Limiter les tentatives de connexion

WordPress ne limite pas les tentatives de connexion. Une extension (Wordfence, Limit Login Attempts Security, Kadence Security) ou une règle serveur doit bloquer l’adresse IP après quelques échecs, y compris sur XML-RPC et sur la connexion WooCommerce.

Mots de passe d’application et clés d’API

Les mots de passe d’application (WordPress 5.6) donnent à un service externe un accès à l’API REST sans le vrai mot de passe, mais avec tous les droits de l’utilisateur. Un par intégration, révoqué dès qu’il ne sert plus ; si personne ne s’en sert, désactivez la fonction (mu-plugin plus bas). Même logique pour les clés d’API tierces : droits minimaux, stockage dans wp-config.php ou en variable d’environnement, rotation après le départ d’un prestataire.

Énumération des utilisateurs via l’API REST

L’adresse /wp-json/wp/v2/users liste à n’importe quel visiteur les auteurs du site et leur slug, souvent identique à l’identifiant de connexion : la moitié d’une attaque par force brute. Le mu-plugin plus bas retire ces routes aux visiteurs non connectés ; vérifiez avant qu’aucune fonction publique du site ne s’en sert. Les archives d’auteur (/?author=1) exposent aussi ces identifiants : masquer gêne les robots, mais ne remplace ni la 2FA ni la limitation des tentatives.

Durcir la configuration : wp-config.php, fichiers et XML-RPC

Ces réglages sans extension limitent ce qu’un attaquant peut tirer d’une faille. Testez-les en préproduction : une règle serveur mal placée peut couper le site.

Les constantes de sécurité de wp-config.php

// wp-config.php, AVANT la ligne « That's all, stop editing! » (ou sa traduction).
// Une constante ne se définit qu'une fois : si elle existe déjà, modifiez sa valeur.

// Désactive l'éditeur de thèmes et d'extensions du tableau de bord.
define( 'DISALLOW_FILE_EDIT', true );

// Plus strict : bloque aussi l'installation et la mise à jour depuis l'admin,
// ainsi que les mises à jour automatiques (y compris de sécurité).
// À n'activer que si les mises à jour passent par WP-CLI, un outil de gestion ou un déploiement.
// define( 'DISALLOW_FILE_MODS', true );

// Aucune erreur PHP affichée aux visiteurs. WP_DEBUG est déjà défini plus haut
// dans le fichier : laissez-le à false en production.
define( 'WP_DEBUG_DISPLAY', false ); // Reste coupé si WP_DEBUG passe à true pour un diagnostic.
ini_set( 'display_errors', '0' );

// Correctifs du cœur (versions mineures) automatiques ; les versions majeures,
// automatiques par défaut sur les sites installés depuis WordPress 5.6, passent par la préproduction.
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_EDIT empêche un administrateur volé de coller du code dans l’éditeur du tableau de bord. DISALLOW_FILE_MODS bloque aussi les mises à jour depuis l’admin et les mises à jour automatiques : à réserver aux sites mis à jour autrement. Les clés et les sels doivent être uniques et régénérés après tout incident, avec le générateur officiel ou wp config shuffle-salts (tout le monde est déconnecté).

Droits des fichiers et exécution de PHP dans les médias

La documentation officielle de durcissement recommande 755 pour les dossiers, 644 pour les fichiers et un wp-config.php plus restreint. Le bon réglage dépend de l’utilisateur qui exécute PHP : vérifiez avec votre hébergeur.

# Quand PHP s'exécute sous l'utilisateur propriétaire des fichiers
find /chemin/vers/wordpress -type d -exec chmod 755 {} \;
find /chemin/vers/wordpress -type f -exec chmod 644 {} \;
chmod 440 /chemin/vers/wordpress/wp-config.php   # ou 400, selon l'utilisateur du processus PHP

Interdire PHP dans wp-content/uploads neutralise la plupart des scripts déposés par une extension vulnérable. Sur Apache 2.4, la directive est Require all denied : l’ancienne syntaxe Order allow,deny, encore très recopiée, date d’Apache 2.2.

# 1. wp-content/uploads/.htaccess : aucun script PHP exécuté dans les médias
<FilesMatch "\.(?i:php[0-9]?|pht|phtml|phar)$">
    Require all denied
</FilesMatch>

# 2. .htaccess racine, AU-DESSUS du bloc « # BEGIN WordPress »
Options -Indexes
<Files "wp-config.php">
    Require all denied
</Files>
# Seulement si aucun service n'utilise XML-RPC (voir plus bas)
<Files "xmlrpc.php">
    Require all denied
</Files>

Sur nginx, les blocs location à expression régulière sont lus dans l’ordre : la règle doit précéder celle qui transmet les fichiers PHP à PHP-FPM.

# Bloc server, AVANT le bloc « location ~ \.php$ »
location ~* ^/wp-content/uploads/.*\.(php[0-9]?|pht|phtml|phar)$ {
    deny all;
}
location = /xmlrpc.php {
    deny all;
}

XML-RPC : couper ce qui ne sert pas

XML-RPC, l’ancienne interface de publication à distance remplacée par l’API REST, sert surtout aux essais de mots de passe et aux pingbacks abusifs. Vérifiez d’abord que Jetpack ou une application de publication n’en dépend pas. Piège classique : le filtre xmlrpc_enabled ne coupe que les méthodes qui demandent une connexion. Sa documentation, dans le code de WordPress, le précise : les pingbacks restent actifs. D’où le filtre xmlrpc_methods ci-dessous, ou mieux, le blocage de xmlrpc.php sur le serveur. Wordfence peut aussi le désactiver.

Un mu-plugin pour regrouper ces réglages

Ces filtres n’ont rien à faire dans le functions.php du thème, qui disparaît au changement de thème. Placez-les dans wp-content/mu-plugins/durcissement.php : les « must-use plugins » se chargent automatiquement et ne se désactivent pas depuis l’admin.

<?php
/**
 * Plugin Name: Durcissement du site
 * Description: Réglages de sécurité indépendants du thème (XML-RPC, API REST, mots de passe d'application).
 */

defined( 'ABSPATH' ) || exit;

// XML-RPC : coupe les méthodes qui demandent une connexion (publication, essais de mots de passe).
add_filter( 'xmlrpc_enabled', '__return_false' );

// ... et retire les pingbacks, que le filtre précédent laisse actifs.
add_filter(
	'xmlrpc_methods',
	static function ( $methods ) {
		unset( $methods['pingback.ping'], $methods['pingback.extensions.getPingbacks'] );
		return $methods;
	}
);

// API REST : la liste des utilisateurs n'est plus servie aux visiteurs non connectés.
add_filter(
	'rest_endpoints',
	static function ( $endpoints ) {
		if ( ! is_user_logged_in() ) {
			unset( $endpoints['/wp/v2/users'], $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
		}
		return $endpoints;
	}
);

// Mots de passe d'application : à désactiver seulement si aucune intégration ne s'en sert.
add_filter( 'wp_is_application_passwords_available', '__return_false' );

Sécuriser wp-admin sans se compliquer la vie

Si une ou deux personnes seulement se connectent, depuis des adresses fixes, réservez wp-login.php à ces adresses IP (Require ip sur Apache) ou ajoutez une authentification HTTP. Ne bloquez jamais wp-admin/admin-ajax.php, utilisé par le site public, et oubliez cette solution si des clients ou des membres se connectent. Inutile d’ajouter X-Frame-Options à l’administration : WordPress l’envoie déjà sur le tableau de bord et la page de connexion.

Pare-feu applicatif (WAF) : extension, serveur ou réseau

Un pare-feu d’application web bloque les requêtes qui ressemblent à une attaque (injection SQL, XSS, faille connue d’une extension, force brute). Il fait gagner du temps entre la publication d’une faille et votre mise à jour. Il existe à trois niveaux :

• dans WordPress, en extension : il connaît WordPress, mais s’exécute avec PHP ;
• sur le serveur, avant WordPress : c’est ce que comprennent mes offres d’hébergement WordPress infogéré, avec la détection d’intrusion ;
• en amont, sur le réseau (CDN, proxy) : seul ce niveau absorbe un déni de service (DDoS). Aucune extension n’arrête un DDoS : quand la requête atteint PHP, le serveur est déjà saturé.

Ce que j’utilise : Wordfence

Sur les sites que je maintiens, Wordfence assure le pare-feu applicatif et l’analyse des fichiers. À l’installation, le pare-feu passe d’abord quelques jours en mode apprentissage, le temps de reconnaître le trafic normal du site. Activez ensuite la « protection étendue », qui le charge avant WordPress (directive PHP auto_prepend_file). Dans la version gratuite, les nouvelles règles et signatures arrivent avec 30 jours de retard sur la version payante.

Quelle extension de sécurité choisir ?

Une seule extension de pare-feu à la fois : deux pare-feux applicatifs se gênent et ralentissent le site. Les principales extensions du répertoire officiel, toutes maintenues et testées avec WordPress 7.1.3 :

HTTPS et en-têtes de sécurité HTTP

Un certificat gratuit chiffre exactement comme un certificat payant ; j’explique ce que garantit, ou non, un certificat Let’s Encrypt dans un article dédié. Côté serveur, n’acceptez que TLS 1.2 et 1.3, contrôlez la configuration avec SSL Labs et surveillez le renouvellement automatique. Les en-têtes HTTP, eux, ne corrigent aucune faille, mais ils limitent l’exploitation de certaines (XSS, clickjacking, retour au HTTP).

HSTS : forcer le HTTPS

Strict-Transport-Security oblige le navigateur à n’utiliser que le HTTPS. Commencez avec un max-age de 300 secondes, vérifiez, puis passez à un an (31536000). includeSubDomains seulement si tous les sous-domaines sont en HTTPS ; l’inscription sur la liste de préchargement est difficile à annuler.

X-Content-Type-Options, Referrer-Policy et Permissions-Policy

X-Content-Type-Options: nosniff empêche d’interpréter un fichier téléversé comme un script. Referrer-Policy: strict-origin-when-cross-origin ne transmet aux autres sites que le domaine d’origine. Permissions-Policy coupe les fonctions du navigateur inutiles au site (caméra, micro, géolocalisation) : adaptez la liste si une page s’en sert.

Content-Security-Policy : commencer petit

La Content-Security-Policy est l’en-tête le plus efficace contre le XSS, et le plus facile à rater. Sur un site Avada ou Elementor, riche en scripts en ligne, une CSP stricte demande un vrai inventaire. Commencez par frame-ancestors 'self', qui interdit l’affichage du site dans un cadre sur un autre domaine. Une politique complète passe d’abord par Content-Security-Policy-Report-Only : le navigateur signale ce qu’il aurait bloqué, sans rien casser.

Où poser les en-têtes

Dans la configuration du serveur plutôt qu’en PHP : un en-tête ajouté par WordPress (hook send_headers) n’accompagne pas les pages qu’une extension de cache sert sans exécuter WordPress. Avec nginx, un add_header placé dans un bloc location annule tous ceux du bloc server.

# Apache 2.4 (mod_headers), virtual host ou .htaccess racine
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=300"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>

# nginx, bloc server (à répéter dans tout bloc location qui a ses propres add_header)
add_header Strict-Transport-Security "max-age=300" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "frame-ancestors 'self'" always;

Vérifiez le résultat dans l’onglet Réseau du navigateur, sur une page en cache comme sur une page qui ne l’est pas.

Sauvegardes externalisées et testées

La sauvegarde rattrape tout le reste, à trois conditions (voir aussi la documentation officielle) :

• hors du serveur : une copie locale disparaît, ou se fait chiffrer, avec lui ;
• plusieurs points de restauration : une infection peut rester discrète des semaines ;
• une restauration testée : une sauvegarde jamais restaurée n’est qu’une hypothèse.

La fréquence suit le rythme du site : une boutique qui reçoit des commandes toute la journée n’a pas les besoins d’un site vitrine. Sur les sites que je maintiens, une sauvegarde complète précède chaque série de mises à jour, et les sauvegardes automatiques prévues par le forfait sont stockées hors du serveur avec WP Umbrella.

Surveiller et journaliser pour réagir vite

Une intrusion repérée tôt se règle vite ; découverte trois mois plus tard, elle a eu le temps de semer des portes dérobées. La surveillance tient en trois volets :

• disponibilité : WP Umbrella vérifie en permanence que les sites que je suis répondent et m’alerte dès que l’un d’eux tombe ;
• intégrité et vulnérabilités : l’analyse de Wordfence compare les fichiers aux originaux, cherche les codes malveillants connus et signale les extensions vulnérables ;
• journal d’activité : connexions, changements de rôle, installations d’extensions, le tout complété par les journaux du serveur, indispensables pour comprendre un incident.

Les signaux externes de Google

Le rapport « Problèmes de sécurité » de la Search Console signale le piratage ou les logiciels malveillants détectés par Google. L’état de navigation sécurisée indique si les navigateurs affichent un avertissement sur votre domaine, et Sucuri SiteCheck offre un contrôle externe ponctuel.

Si une intrusion est confirmée : isoler le site, trouver la porte d’entrée, restaurer une sauvegarde antérieure à l’attaque, fermer la faille, puis changer mots de passe, clés et sels. Sans la faille fermée, l’attaque recommence. Voici comment se déroule mon intervention après une intrusion.

Les fausses bonnes idées

La documentation officielle le dit : la sécurité par l’obscurité n’est pas une stratégie. Ces astuces, présentes dans presque toutes les listes, rapportent peu :

• Cacher la version de WordPress : les robots testent les failles sans la lire. Un site en retard reste vulnérable, version affichée ou non.
• Changer le préfixe wp_ des tables : une injection SQL lit le vrai préfixe en une requête, et le changement casse surtout des extensions. La réponse à une injection SQL, c’est la mise à jour de l’extension fautive.
• Renommer l’URL de connexion : moins de bruit dans les journaux, mais XML-RPC et l’API REST restent ouverts. Ce n’est pas un substitut à la 2FA.
• Empiler les extensions de sécurité : conflits, règles en double, site ralenti.
• Croire un code sur mesure sûr parce qu’il est unique : il l’est quand il vérifie les droits, valide les entrées et échappe les sorties.

Checklist d’audit de sécurité WordPress

Un audit se fait au moins une fois par an, et après chaque changement important (refonte, nouveau prestataire, nouvel hébergeur). Voici ce que je vérifie :

• cœur, extensions et thème à jour ; aucune extension abandonnée, désactivée ou « nulled » ;
• version de PHP encore couverte par des correctifs de sécurité ;
• fichiers du cœur et des extensions identiques aux originaux ;
• administrateurs passés en revue, 2FA active sur tous les comptes à privilèges ;
• tentatives de connexion limitées, XML-RPC fermé s’il ne sert pas ;
• DISALLOW_FILE_EDIT, erreurs PHP masquées, droits des fichiers, PHP interdit dans uploads ;
• HTTPS partout, en-têtes présents, y compris sur les pages en cache ;
• pare-feu actif, aucune alerte d’analyse en suspens, rien dans la Search Console ;
• dernière sauvegarde hors serveur récente, dernière restauration testée.

wp core version                        # version de WordPress
wp core verify-checksums               # fichiers du cœur modifiés ou ajoutés
wp plugin verify-checksums --all       # extensions du répertoire wordpress.org seulement
wp plugin list --update=available --fields=name,version,update_version
wp plugin list --status=inactive       # à supprimer plutôt qu'à garder désactivées
wp user list --role=administrator --fields=ID,user_login,user_registered

La version de PHP qui sert réellement le site se lit dans Outils > Santé du site > Informations : WP-CLI tourne parfois avec un autre PHP que le serveur web. wp plugin verify-checksums ne couvre que les extensions du répertoire officiel : les extensions premium se contrôlent avec l’analyse de Wordfence ou en les réinstallant depuis le site de l’éditeur.

Sur un site qui contient du code sur mesure, l’audit ajoute une revue de ce code : droits (current_user_can()) et nonces sur chaque action, entrées assainies, sorties échappées, requêtes préparées avec $wpdb->prepare(). Pour un site à fort enjeu (paiement, espace client, données sensibles), un test d’intrusion par un spécialiste trouve les failles de logique que les outils automatiques ne voient pas.

Questions fréquentes sur la sécurité WordPress

En résumé

Sécuriser WordPress est d’abord une question d’ordre : mises à jour testées, comptes protégés par la double authentification, configuration qui ferme ce qui ne sert pas, puis pare-feu, sauvegardes et surveillance. Les astuces d’obscurité viennent en dernier.

C’est un travail régulier plus qu’un réglage unique. Si vous préférez le déléguer, c’est ce que couvrent mes forfaits de maintenance WordPress : mises à jour testées en préproduction, Wordfence et surveillance continue, avec des sauvegardes externalisées selon le forfait. Pour situer le budget, voici ce que coûte une maintenance WordPress.

Mis à jour en octobre 2026 (WordPress 7.1.3) par un développeur WordPress freelance senior.