Vous avez mis votre site à jour il y a trois mois et vous vous dites que c'est bon ? Vous savez combien de comptes administrateur existent dessus ? Et à quand remonte la dernière sauvegarde dont vous avez réellement testé la restauration ?
La sécurité WordPress ne se joue presque jamais dans les grandes théories. Elle se joue dans neuf réglages que personne ne reprend une fois le site livré : une extension oubliée, un wp-config.php laissé par défaut, un xmlrpc.php ouvert parce que « ça a toujours marché ».
Je travaille sur WordPress depuis 2012 et c'est la liste que je déroule sur chaque site que je reprends. Pour chaque réglage : la valeur exacte à appliquer, où la changer, et la faille qu'elle bloque. Vous pouvez tout faire vous-même - et si à la fin vous préférez sécuriser un site WordPress sans y passer vos soirées, vous saurez au moins ce que vous déléguez.
Voilà la liste complète, dans l'ordre où je la vérifie. Un site neuf ou repris : les neuf d'un coup. Ensuite, les réglages 1, 3 et 9 reviennent chaque mois, les autres se contrôlent une fois puis se revérifient une à deux fois par an.
| # | Réglage | Valeur à appliquer | Faille bloquée |
|---|---|---|---|
| 1 | Mises à jour | WordPress 7.1.4, extensions et thème à jour, après une sauvegarde | Exploitation d'une faille déjà corrigée et rendue publique |
| 2 | Comptes admin | 1 seul administrateur, mot de passe de 12 caractères minimum, double authentification active | Force brute et vol d'identifiants |
| 3 | Extensions | Aucune extension inactive, aucune sans mise à jour depuis 2 ans | Faille d'une extension abandonnée (91 % des vulnérabilités publiées) |
| 4 | Droits des fichiers | 755 pour les dossiers, 644 pour les fichiers, 440 pour wp-config.php |
Injection de code dans un fichier modifiable par le serveur web |
| 5 | wp-config.php |
DISALLOW_FILE_EDIT à true, clés de sécurité régénérées, débogage éteint |
Exécution de code depuis l'éditeur de fichiers de l'admin |
| 6 | XML-RPC | Bloqué au niveau du serveur si vous ne l'utilisez pas | Force brute qui contourne le comptage des tentatives |
| 7 | HTTPS | HTTPS partout, FORCE_SSL_ADMIN à true, une seule redirection |
Interception du mot de passe et du cookie de session admin |
| 8 | Sauvegardes | Copie hors site quotidienne, restauration testée | Perte définitive des données après chiffrement ou suppression |
| 9 | Surveillance | Alertes sur fichiers et connexions, test des formulaires 1×/mois | Intrusion active pendant des semaines sans que personne ne la voie |
Les réglages 1 à 3 se font dans l'admin, les 4 et 6 chez l'hébergeur ou dans .htaccess, les 5 et 7 dans wp-config.php. Pour tout le reste des manipulations WordPress, nos guides sont rangés dans la rubrique WordPress.
Les failles WordPress dont on parle le plus ne sont pas des failles de WordPress. Sur les vulnérabilités publiées en 2025, Patchstack en recense 10 230 dans des extensions (91 %), 1 009 dans des thèmes (9 %) et 2 dans le cœur (source consultée le 12 novembre 2026). Autrement dit : le noyau est rarement le problème, tout ce qu'on greffe autour l'est.
Ce que ces chiffres disent aussi, c'est la nature des failles : 40,68 % de cross-site scripting, 15,15 % de contrôle d'accès cassé, 12,93 % de CSRF, 5,75 % d'injection SQL. Et 42 % des vulnérabilités publiées sur cette période n'avaient pas de correctif au moment du relevé. Une faille de sécurité WordPress n'est donc pas un scénario rare et exotique : c'est un défaut banal dans un code que vous n'avez pas écrit.
Concrètement, un site se fait pirater par quatre portes, toujours les mêmes :
xmlrpc.php qui permet d'envoyer des dizaines de tentatives en une requête ;Et « piraté » ne veut pas seulement dire « site cassé ». Un site compromis peut afficher un avertissement dans les résultats de recherche Google, ce qui coupe le trafic ; il peut servir à envoyer du spam depuis votre nom de domaine ; et s'il collecte des données personnelles (formulaire de contact, commandes, comptes clients), vous avez un problème RGPD en plus du problème technique. C'est ce qui change la donne : vous ne protégez pas seulement un site, vous protégez une activité et des données.
La version stable de WordPress au moment où j'écris est la 7.1.4 (wordpress.org/download, consulté le 12 novembre 2026). Si votre admin affiche autre chose, vous avez du retard.
L'ordre compte, parce qu'une mise à jour peut casser quelque chose :
Pourquoi c'est le réglage n° 1 : dès qu'une version corrige une faille, l'information permettant de l'exploiter devient publique. Les sites en retard ne sont pas attaqués à la main, ils sont scannés en masse. Vous trouverez la procédure détaillée, y compris le cas « la mise à jour casse le site », dans notre tutoriel mettre à jour WordPress.
Trois choses à faire, dans cet ordre.
Un seul compte administrateur. Sur notre propre site, il n'y en a qu'un. Chaque personne supplémentaire qui a besoin de publier prend un rôle éditeur ou auteur - pas administrateur « pour que ce soit plus simple ». Un compte admin oublié, c'est une porte dont vous ne surveillez plus la serrure.
Un mot de passe qui tient. La CNIL recommande par défaut une entropie minimale de 80 bits, soit concrètement 12 caractères mêlant majuscules, minuscules, chiffres et caractères spéciaux (ou 14 caractères sur trois types). Pas de renouvellement périodique obligatoire pour un utilisateur ordinaire, mais un gestionnaire de mots de passe et un mot de passe unique par site.
La double authentification. WordPress n'en embarque pas nativement : elle vient d'une extension (Two-Factor, Wordfence Login Security, Google Authenticator…). Sur notre site, Wordfence et son module Login Security sont installés, et on masque l'URL de connexion avec WPS Hide Login pour que /wp-admin ne soit plus la porte d'entrée évidente. La CNIL a publié le 20 mars 2025 une recommandation dédiée à l'authentification multifacteur (délibération n° 2025-019) : elle la considère comme la mesure à privilégier dès que le risque le justifie, ce qui est le cas d'un accès administrateur exposé sur Internet.
La faille bloquée ici est la plus banale et la plus efficace : un mot de passe deviné sur un compte admin, c'est un accès complet au site, à la base et souvent au serveur.
91 % des vulnérabilités WordPress publiées en 2025 concernaient des extensions. La conclusion est mécanique : le tri des extensions est l'action la plus rentable pour sécuriser un site WordPress.
Ouvrez Extensions → Extensions installées et regardez trois colonnes :
Deux signaux plus forts encore : l'extension a été fermée sur WordPress.org, ou son nom apparaît dans une base d'avis de vulnérabilité sans correctif disponible. Dans les deux cas, on remplace, on ne discute pas.
Et on supprime. Une extension désactivée mais présente reste un dossier sur le serveur, avec ses fichiers et ses éventuelles failles. Si elle ne sert pas, elle part. Si vous hésitez à la remplacer, faites-le sur une copie du site (environnement de préproduction) avant de toucher à la production.
C'est le réglage serveur que presque personne ne vérifie, et c'est celui qui décide de ce qu'un attaquant peut faire après être entré. La documentation de durcissement de WordPress.org donne une règle simple :
| Élément | Valeur | Ce que ça autorise |
|---|---|---|
| Dossiers | 755 | Propriétaire : lecture, écriture, exécution. Les autres : lecture et traversée |
| Fichiers | 644 | Propriétaire : lecture et écriture. Les autres : lecture seule |
wp-config.php |
440 (ou 400) | Lecture seule par le propriétaire et le groupe uniquement |
Jamais 777, sur rien, jamais. Un dossier en 777 est un dossier où le serveur web - donc un script injecté - peut écrire et exécuter ce qu'il veut. C'est exactement le mécanisme utilisé pour transformer une faille mineure en site entièrement compromis.
Avec un accès SSH, la correction prend deux commandes :
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.phpSans SSH, vous pouvez passer par votre client FTP/SFTP : clic droit sur le dossier wp-content, permissions, et vous lisez les valeurs. Sur certains hébergements mutualisés, c'est l'hébergeur qui impose les droits : demandez-lui la valeur appliquée avant de bricoler. À noter : quand WordPress fait lui-même une mise à jour automatique, il réécrit les fichiers en 0644 et les dossiers en 0755 - si vous trouvez du 777 quelque part, ce n'est pas WordPress qui l'a mis là.
Le wp-config.php contient le mot de passe de votre base de données et les clés d'authentification. Deux gestes : le protéger, puis en retirer les outils qui servent l'attaquant.
Le protéger. Gardez-le en 440 (ou 400) et, si votre serveur lit .htaccess, ajoutez en tout début de fichier :
<Files "wp-config.php">
Require all denied
</Files>Le durcir. Ajoutez ces lignes avant le commentaire « C'est tout, arrêtez d'éditer ! » :
define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', false );DISALLOW_FILE_EDIT supprime l'éditeur de fichiers de l'admin. Ce n'est pas un détail cosmétique : c'est le premier outil qu'un attaquant utilise quand il obtient un accès administrateur, parce qu'il permet d'exécuter du code en trois clics. Ne le confondez pas avec DISALLOW_FILE_MODS, qui bloque aussi les installations et mises à jour d'extensions - utile dans certains cas, mais qui vous empêchera de mettre à jour depuis l'admin.
Les trois constantes de débogage, à false, évitent d'afficher les chemins serveur et les erreurs PHP aux visiteurs. Si vous devez diagnostiquer, activez temporairement WP_DEBUG_LOG et jamais WP_DEBUG_DISPLAY sur un site en production.
Régénérer les clés de sécurité. Huit constantes (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs *_SALT) servent à signer les cookies de connexion. Générez-en de nouvelles avec le générateur officiel de WordPress.org, jamais en copiant un exemple trouvé dans un tutoriel. Effet de bord immédiat : toutes les sessions ouvertes sont déconnectées. C'est exactement ce qu'on veut après un doute ou un piratage - et c'est aussi pour ça qu'on ne le fait pas un vendredi à 17 h sans prévenir les personnes concernées.
xmlrpc.php est une porte d'entrée historique de WordPress, encore ouverte par défaut. Elle sert à Jetpack, à l'application mobile WordPress et à quelques outils de publication à distance. Si vous n'utilisez aucun des trois, elle ne sert à rien - sauf à ceux qui tentent des identifiants.
Le test, en 10 secondes : ouvrez https://votresite.fr/xmlrpc.php. Si vous obtenez une réponse de WordPress au lieu d'une erreur 403 ou 404, le point d'entrée est ouvert.
La fermeture, au niveau du serveur (le plus efficace, la requête est bloquée avant même que WordPress ne démarre). Apache, dans .htaccess, en dehors des balises gérées par WordPress :
<Files "xmlrpc.php">
Require all denied
</Files>Nginx, dans le bloc server :
location = /xmlrpc.php {
deny all;
}Si vous n'avez pas la main sur le serveur, un filtre xmlrpc_enabled à false dans un petit plugin maison désactive les méthodes authentifiées, mais ne bloque pas l'accès au fichier : une protection partielle, à réserver aux hébergements fermés.
Pourquoi c'est dans la liste : XML-RPC accepte d'envoyer plusieurs tentatives de connexion dans une seule requête, ce qui rend inefficace une protection qui compte les essais par requête. Une attaque par force brute peut y passer des milliers d'identifiants sans déclencher de blocage. Si vous avez besoin de XML-RPC (Jetpack, app mobile), gardez-le mais limitez les tentatives de connexion et la fréquence des requêtes.
Un site en HTTP, c'est un mot de passe administrateur qui circule en clair sur le Wi-Fi d'un hôtel. La sécurité d'un site WordPress se joue aussi là, et c'est vérifiable en trois minutes :
https://.wp-config.php : define( 'FORCE_SSL_ADMIN', true ); - la connexion et les sessions d'administration passent alors obligatoirement en SSL.http://votresite.fr doit renvoyer vers https://votresite.fr en une seule étape. Une chaîne http → https://www → https:// coûte du temps de chargement et brouille le crawl.http:// dans une page https déclenche un avertissement navigateur et casse parfois la mise en page.Cette dernière étape (redirections propres, sans boucle, sans double slash) est celle où l'on casse le plus de choses en croyant bien faire. Elle est détaillée pas à pas dans rediriger un site WordPress en HTTPS.
La faille bloquée : l'interception de session. Un cookie d'administration volé sur une connexion non chiffrée donne un accès complet sans avoir besoin de deviner le moindre mot de passe.
Une sauvegarde qui vit sur le même serveur que le site n'est pas une sauvegarde. Le jour où le serveur est chiffré, suspendu ou effacé, elle disparaît avec le reste.
Ce que je vérifie :
Sur notre propre site, on utilise UpdraftPlus et Duplicator Pro, sauvegardes automatiques et manuelles. Peu importe l'outil : ce qui compte est l'écart entre « j'ai une sauvegarde » et « je peux remettre le site en ligne ce soir ». Le tutoriel complet est ici : sauvegarder un site WordPress.
C'est le seul réglage des neuf qui ne bloque aucune attaque - mais c'est le seul qui répare un site déjà compromis sans perdre le contenu de trois ans.
Les huit réglages précédents réduisent le risque. Celui-ci réduit la durée. Une intrusion non détectée peut rester active des semaines ; une alerte le même jour change tout.
Ce qui doit remonter jusqu'à vous :
wp-content (un scan de fichiers avec alertes) ;Sur notre site, c'est Wordfence Security qui tient le pare-feu et les alertes, avec WPS Hide Login pour la porte dérobée de l'admin. Un plugin de sécurité ne remplace pas les huit réglages précédents, il les surveille. Et cette surveillance n'a de valeur que si quelqu'un la lit : une boîte mail pleine d'alertes non lues revient au même que pas de surveillance du tout.
Si vous découvrez une page étrangère, une redirection vers un site inconnu ou un avertissement Google, respirez et suivez cet ordre. Le réflexe « je supprime tout et je réinstalle » fait souvent perdre les preuves nécessaires pour comprendre par où c'est entré - et donc pour éviter que ça recommence la semaine suivante.
wp-config.php : toutes les connexions en cours tombent, y compris celle de l'attaquant..htaccess, index.php à la racine et les dossiers uploads : c'est là que se logent les redirections et les fichiers PHP déposés.Sur ce terrain, deux choses à savoir avant de paniquer ou de payer : le nettoyage d'un site WordPress piraté démarre à 150 €HT, et un site en panne ou inaccessible est dépanné en 2 h à partir de 75 €HT, avec diagnostic gratuit avant intervention et dépannage garanti 30 jours. Le déroulé complet des gestes, y compris ce qu'il ne faut surtout pas faire, est dans que faire quand son site WordPress est piraté.
Reprenons honnêtement. Les neuf réglages, la première fois, c'est une demi-journée quand tout se passe bien - et une journée quand il faut négocier avec un hébergeur, récupérer un accès FTP perdu et tester une restauration. Ensuite, en régime normal :
On arrive autour de 1 h à 1 h 30 par mois pour tenir la barre, avec des pics. Si vous facturez votre propre heure 50 €HT (hypothèse de calcul, ajustez à votre tarif), cela représente environ 50 à 75 €HT de temps par mois - soit l'ordre de grandeur de la formule de maintenance WordPress tout compris : 752 €HT/an, soit 62,67 €HT/mois. Elle inclut la mise à jour hebdomadaire de WordPress, du thème et des extensions, le diagnostic et la correction des failles, les sauvegardes automatiques et manuelles, l'accès aux extensions et thèmes premium, l'intervention 7j/7 et 365j/an, le rapport mensuel et le test des formulaires. Le détail est sur la page maintenance WordPress et les tarifs.
Là où le calcul bascule vraiment, ce n'est pas le prix : c'est ce qui se passe le jour où quelque chose casse. Un site en panne un samedi soir, une alerte de connexion suspecte, une mise à jour majeure qui casse le formulaire de contact - dans ces moments-là, il faut quelqu'un qui reprend le site en main, pas un tutoriel. C'est aussi pour ça que je reste un freelance et pas une agence : un seul interlocuteur, qui connaît votre installation, avec une intervention 7j/7. Si vous voulez d'abord savoir où vous en êtes, un audit WordPress donne l'état des neuf points ci-dessus avant de décider quoi que ce soit.
Non, et personne ne peut vous le promettre. La documentation officielle de durcissement de WordPress le dit elle-même : la sécurité est une réduction du risque, pas une élimination. Une faille de sécurité WordPress peut apparaître demain dans une extension que personne ne soupçonnait. L'objectif réaliste : réduire les portes d'entrée, détecter vite, et pouvoir restaurer sans rien perdre.
Les mises à jour, le tri des extensions et la surveillance reviennent chaque mois. Les droits de fichiers, wp-config.php, XML-RPC et le HTTPS se contrôlent une fois, puis se revérifient une à deux fois par an - et systématiquement après un changement d'hébergeur, une refonte ou l'installation d'une nouvelle extension. La sauvegarde, elle, se vérifie chaque mois sur son exécution et chaque trimestre sur sa restauration.
Non. Un plugin de pare-feu filtre des attaques connues, il n'annule pas un mot de passe faible, une extension abandonnée ni un fichier en 777. Les 91 % de vulnérabilités logées dans des extensions montrent bien que le problème est dans le code installé, pas dans la couche de filtrage. Le plugin est la neuvième ligne de la liste, pas la première.
Un site compromis peut afficher un avertissement « ce site risque d'endommager votre ordinateur » dans les résultats de recherche, et Google peut retirer des pages piratées de son index. Le trafic chute alors immédiatement, y compris sur des pages saines, et l'avertissement ne disparaît qu'après nettoyage et demande de réexamen dans la Search Console. Autrement dit : le coût d'un piratage se compte aussi en visites perdues et en confiance abîmée.
Comptez une demi-journée pour la première passe des neuf réglages sur un site existant, puis 1 h à 1 h 30 par mois pour la tenir. Le temps se concentre sur trois choses : tester réellement les formulaires et la restauration, lire les alertes, et gérer les mises à jour qui cassent quelque chose.
Mises à jour chaque semaine, extensions surveillées, sauvegardes hors site et intervention 7j/7 : avec notre maintenance WordPress, ces neuf réglages sont tenus dans la durée, pour 752 €HT/an.
