Sécurité site WordPress : le guide pratique pour blinder son installation

Quarante-trois pour cent du web tourne sous WordPress. Ça en fait une cible énorme pour les attaques automatisées. Pas parce que WordPress est mauvais, mais parce qu’il y a tellement d’installations mal configurées qu’un bot a statistiquement raison de tester systématiquement chaque IP qui répond sur /wp-login.php.

La bonne nouvelle, c’est que la sécurité d’un site WordPress repose sur une dizaine de réglages techniques. Aucun n’est compliqué, aucun ne demande de compétences pointues en cybersécurité. Le problème, c’est que personne ne les fait tous. On fait les mises à jour mais on garde un mot de passe à six caractères. On installe Wordfence mais on oublie de désactiver XML-RPC. Un site protégé à 70%, c’est un site qui finira piraté.

Ce guide reprend les vrais piliers de la sécurité WordPress, avec les bouts de code, les plugins et les arbitrages qu’on applique en agence sur les sites en production. À la fin, vous saurez exactement quoi vérifier sur votre installation.

Pourquoi un site WordPress se fait pirater (et ce que « piraté » veut dire concrètement)

Premier réflexe à corriger : WordPress n’est pas vulnérable en lui-même. Le cœur du CMS est audité, corrigé en continu par une communauté massive, et les failles critiques sont patchées en quelques heures. Quand un site WordPress tombe, dans 90% des cas c’est à cause d’un de ces trois trucs :

• Un plugin ou un thème pas à jour avec une faille connue, exploitée en masse par des bots qui scannent le web entier
• Un mot de passe administrateur faible ou réutilisé sur un autre service compromis
• Un hébergement mutualisé bas de gamme où un site voisin contaminé sert de point d’entrée

Et « piraté » recouvre des réalités très différentes. Ça peut être un défaçage (la page d’accueil remplacée par un message), une injection de spam SEO (votre site se met à pointer vers des pharmacies en ligne), un cryptominer planqué dans les fichiers, un envoi massif d’emails depuis votre serveur, ou pire : un ransomware qui chiffre la base de données. Les conséquences vont de quelques heures de nettoyage à une perte totale de référencement et de réputation.

Les stats Wordfence sur 2025 montrent que les attaques par force brute représentent encore plus de 60% du trafic malveillant détecté. C’est bête, c’est massif, et ça marche tant que les sites laissent admin comme identifiant ou n’ont aucune limite de tentatives de connexion.

Verrouiller les accès : mots de passe, 2FA et URL de connexion

L’écrasante majorité des intrusions commence ici. Un bot trouve /wp-login.php (présent par défaut sur tout WordPress), tente des milliers de combinaisons admin / mots de passe courants, et finit par tomber juste. Trois actions à faire dans l’ordre.

Changer l’identifiant admin. Si votre compte principal s’appelle admin, administrator, ou le nom de domaine, créez un nouveau compte administrateur avec un identifiant non devinable, connectez-vous dessus, puis supprimez l’ancien en réattribuant les contenus. Ça divise déjà par dix les chances qu’une attaque brute force aboutisse.

Mots de passe de 16 caractères minimum, générés aléatoirement. Bitwarden, 1Password ou KeePass font le job gratuitement. Pas de mot de passe basé sur le nom de l’entreprise, l’année, ou le prénom du chien. Et ce mot de passe ne doit jamais servir ailleurs : si LinkedIn fuite (encore), votre WordPress doit rester intact.

Authentification à deux facteurs (2FA) pour tous les comptes administrateurs et éditeurs. WP 2FA, Two Factor Authentication ou Wordfence Login Security ajoutent un code TOTP via Google Authenticator ou Authy en quelques minutes. Même si le mot de passe fuite, l’attaquant ne passe pas sans le smartphone.

Masquer l’URL de connexion. Le plugin WPS Hide Login remplace /wp-login.php et /wp-admin par n’importe quelle chaîne (/connexion-perso, /access-2026, etc.). Les bots qui tapent en boucle sur l’URL par défaut reçoivent un 404, et toutes les tentatives qu’on voyait dans les logs disparaissent. Petit effet mais ça fait baisser la charge serveur de façon notable sur les sites visibles.

Les bots qui tapent en boucle sur l’URL par défaut reçoivent un 404, et toutes les tentatives qu’on voyait dans les logs disparaissent. page 404 personnalisée peut aussi contribuer à améliorer la sécurité.

Limiter les tentatives de connexion avec Limit Login Attempts Reloaded ou la fonction équivalente intégrée à Wordfence. Trois échecs et l’IP est bloquée pendant 24h. C’est la dernière brique contre le brute force.

Maintenir le cœur, les plugins, le thème et PHP à jour

Soixante-dix-huit pour cent des sites WordPress piratés tournent avec au moins un composant obsolète. Une faille de plugin annoncée publiquement le matin se transforme en campagne d’exploitation industrielle dans la journée. Ne pas mettre à jour, c’est garder une porte ouverte dont l’adresse circule sur les forums.

Voici le rythme qu’on applique en maintenance d’agence :

Comme pour les plugins WordPress, il est crucial de maintenir son hébergement à jour.

Pour le PHP, c’est souvent oublié. Beaucoup d’hébergeurs laissent les sites tourner en PHP 7.4 ou 8.0 alors que ces versions ne reçoivent plus de patchs de sécurité. Passer en PHP 8.2 améliore la sécurité et fait gagner 15 à 30% sur les temps de chargement. La bascule prend une minute dans le panneau de l’hébergeur, à condition d’avoir vérifié que les plugins suivent.

Désinstallez (vraiment) les plugins inutilisés. Désactivé ne suffit pas, les fichiers restent sur le serveur et peuvent contenir des failles exploitables même sans être actifs. Pareil pour les thèmes : gardez le thème actif, gardez le thème par défaut de WordPress comme filet de sécurité, supprimez tout le reste.

Et un point qu’on oublie : abonnez-vous à une veille de vulnérabilités. Patchstack, Wordfence Intelligence ou la veille de WPFormation envoient une alerte dès qu’un plugin installé sur votre site reçoit un CVE. Sans ça, vous découvrez la faille quand le site est déjà compromis.

Renforcer wp-config.php et les permissions de fichiers

Le fichier wp-config.php contient les identifiants de la base de données et les clés de chiffrement. C’est le fichier le plus sensible de toute l’installation. Quelques réglages à ajouter ou vérifier.

Régénérer les clés SALT. Ces huit clés (AUTH_KEY, SECURE_AUTH_KEY, etc.) servent à chiffrer les cookies de session. Si elles fuient ou si vous reprenez un site qui en a hérité, allez sur https://api.wordpress.org/secret-key/1.1/salt/ et remplacez les huit lignes correspondantes dans wp-config.php. Tous les utilisateurs sont déconnectés, c’est normal.

Désactiver l’éditeur de fichiers depuis l’admin. Si un attaquant accède au back-office, l’éditeur de thèmes/plugins lui permet d’injecter du code malveillant directement. À ajouter dans wp-config.php :

`php define(‘DISALLOW_FILE_EDIT’, true); `

Bloquer l’installation et la mise à jour de plugins depuis l’admin (sur les sites où c’est géré par un développeur uniquement) :

`php define(‘DISALLOW_FILE_MODS’, true); `

Changer le préfixe de la base de données. Par défaut WordPress utilise wp_. Tous les outils d’attaque automatique le savent. Lors de l’installation, mettez un préfixe random : xy7k_, prefix_bzr3_, peu importe. Si le site est déjà en wp_, le plugin Brozzme DB PREFIX Change permet de migrer proprement en une opération.

Permissions de fichiers correctes via SSH ou le gestionnaire de fichiers de l’hébergeur :

`bash

find /chemin/wordpress/ -type d -exec chmod 755 {} ;

find /chemin/wordpress/ -type f -exec chmod 644 {} ;

chmod 600 wp-config.php `

Bloquer l’accès direct à wp-config.php depuis le web via .htaccess :

`apache order allow,deny deny from all `

Désactiver XML-RPC si vous ne l’utilisez pas. Ce protocole sert à l’application mobile WordPress et à certains plugins anciens. Il est devenu un vecteur d’attaque par amplification brute force. Si vous ne savez pas si vous l’utilisez, vous ne l’utilisez probablement pas. Un plugin comme Disable XML-RPC le coupe en un clic, ou directement dans .htaccess :

`apache order deny,allow deny from all `

Installer un pare-feu applicatif : Wordfence, Sucuri ou Cloudflare ?

Un WAF (Web Application Firewall) filtre les requêtes malveillantes avant qu’elles n’atteignent WordPress. Trois solutions dominent le marché, avec des philosophies différentes.

Wordfence s’installe comme un plugin WordPress classique. Il scanne les fichiers à la recherche de malwares, bloque les IP malveillantes en temps réel, et applique des règles de pare-feu spécifiques aux failles connues. Version gratuite déjà très solide. Limite : il consomme des ressources serveur puisqu’il tourne dans WordPress, et la base d’IP malveillantes a 30 jours de retard sur la version premium.

Sucuri propose deux outils : un plugin gratuit pour le scan, et un WAF cloud payant (10$/mois) qui filtre le trafic en amont du serveur. C’est la solution la plus efficace en cas d’attaque DDoS, parce que le trafic malveillant n’arrive jamais sur votre infra. Inclut le nettoyage de site infecté dans certaines offres.

Cloudflare n’est pas un plugin WordPress mais un proxy DNS qui se met devant votre site. Version gratuite : protection DDoS, certificat SSL, cache CDN, règles de pare-feu basiques. Version payante (20$/mois) : WAF complet avec règles OWASP, bot management, et règles personnalisées par geo-IP.

Notre choix par défaut en agence : Cloudflare gratuit en proxy DNS + Wordfence gratuit dans WordPress. Ça couvre 95% des menaces sans coût récurrent, et ça laisse la possibilité de passer en payant le jour où le trafic justifie d’aller plus loin.

Sauvegardes : la stratégie 3-2-1 appliquée à WordPress

Si tout le reste lâche, votre dernier filet c’est la sauvegarde. Pas n’importe laquelle : une sauvegarde testée, récente, et stockée ailleurs que sur le serveur du site. La règle 3-2-1 vient de la cybersécurité d’entreprise et s’applique très bien à WordPress :

• 3 copies des données (production + 2 backups)
• 2 supports différents (disque serveur + cloud par exemple)
• 1 copie hors site (jamais sur la même machine que le site)

Le problème des backups de l’hébergeur, c’est qu’ils sont sur le même serveur. Si le serveur tombe ou se fait compromettre, les backups partent avec. D’où l’importance d’externaliser.

Les plugins qu’on utilise :

• UpdraftPlus (gratuit) : sauvegarde planifiée vers Google Drive, Dropbox, S3. La version premium ajoute la migration et le clonage.
• BackWPup (gratuit) : équivalent, avec une interface un peu plus austère mais très configurable.
• Duplicator Pro (payant) : excellent pour les migrations, intègre la sauvegarde.

Configuration minimale recommandée :

Et le point que tout le monde zappe : testez vos restaurations. Une fois par trimestre, montez une copie du site sur un sous-domaine de staging à partir du dernier backup. C’est la seule façon de vérifier que vos sauvegardes sont exploitables. Une backup corrompue qu’on découvre le jour du piratage, c’est exactement la même chose qu’aucune backup.

Headers HTTP de sécurité et certificat SSL

Le HTTPS est obligatoire en 2026. Google le pénalise dans les résultats, Chrome affiche « Non sécurisé » en clair dans la barre d’adresse, et les données qui transitent en HTTP peuvent être interceptées sur n’importe quel wifi public. Let’s Encrypt fournit des certificats SSL gratuits, automatiquement renouvelés tous les 90 jours par à peu près tous les hébergeurs sérieux. Activation : un clic dans le panneau de l’hébergeur.

Au-delà du SSL, les headers HTTP de sécurité ajoutent une couche de protection contre des attaques côté navigateur. À ajouter dans le .htaccess (Apache) ou la conf Nginx :

`apache

Header set X-Content-Type-Options « nosniff »

Header set X-Frame-Options « SAMEORIGIN »

Header set Strict-Transport-Security « max-age=31536000; includeSubDomains »

Header set Referrer-Policy « strict-origin-when-cross-origin »

Header set Permissions-Policy « geolocation=(), microphone=(), camera=() » `

Le Content-Security-Policy (CSP) est plus complexe à mettre en place parce qu’il dépend des scripts tiers chargés par le site (Google Analytics, Tag Manager, embeds, etc.). On le configure en mode Report-Only d’abord pendant deux semaines pour identifier ce qui casse, puis on bascule en mode actif.

Pour vérifier les headers : securityheaders.com. Score visé : A ou A+. Un site WordPress fraîchement installé est en général noté D ou F, ce qui donne une idée du chemin à parcourir.

Que faire si votre site WordPress est piraté

Malgré tout ça, ça peut arriver. Voici la procédure qu’on applique en intervention d’urgence.

Mettre le site en maintenance immédiatement. Pas en ligne pour servir du malware ou du spam aux visiteurs pendant qu’on enquête. Une page maintenance.html à la racine et un .htaccess qui redirige tout dessus.

Changer tous les mots de passe : admin WordPress, FTP/SSH, base de données, panneau hébergeur, comptes e-mail associés. Considérer comme compromis tout ce qui touche au site.

Identifier la date d’infection via les logs serveur (access.log, error.log) et les dates de modification des fichiers PHP. Les fichiers modifiés récemment qui n’auraient pas dû l’être sont suspects. Un find utile pour partir à la chasse :

`bash find /chemin/wordpress/ -name « *.php » -mtime -7 `

Restaurer le dernier backup propre (antérieur à la date d’infection), pas juste nettoyer. Le nettoyage manuel laisse toujours des portes dérobées que les attaquants exploiteront plus tard. Une restauration depuis backup + remise à jour de tout = repartir sur des bases saines.

Scanner après restauration avec Wordfence en profondeur (Premium permet le scan en temps réel) et avec un outil comme MalCare ou Sucuri SiteCheck depuis l’extérieur. Tant qu’un scan revient propre, on ne remet pas en ligne.

Comprendre comment c’est arrivé. Si on remet en production sans corriger la faille initiale, le site se fait repirater dans la semaine. Plugin obsolète ? Mot de passe faible ? Faille d’un thème nulled (jamais utiliser de thèmes ou plugins crackés, c’est la première source d’infection des sites WordPress) ?

Pour les cas graves, faire appel à un service de nettoyage pro (Sucuri propose ça pour 200$ environ par incident). Le temps qu’on perd à nettoyer soi-même un site bien infecté coûte souvent plus cher que de déléguer.

FAQ sur la sécurité WordPress

.faq-accordion{border:1px solid #e0e0e0;border-radius:8px;margin-bottom:12px;overflow:hidden}.faq-accordion summary{padding:16px 20px;cursor:pointer;font-weight:700;font-size:1.05em;list-style:none;display:flex;align-items:center;gap:10px}.faq-accordion summary::-webkit-details-marker{display:none}.faq-accordion>div{padding:4px 20px 18px 48px;line-height:1.7}

Verdict

La sécurité d’un site WordPress repose sur deux choses : une dizaine de réglages techniques à appliquer une fois, et une discipline de mises à jour et de sauvegardes à tenir dans la durée. Aucun plugin magique, aucune intervention unique qui règle tout. Quand on en fait 80%, on se fait pirater. Quand on en fait 100%, le risque tombe à un niveau acceptable pour la grande majorité des sites professionnels.

Point fort de l’écosystème WordPress : tous les outils existent gratuitement et la documentation est massive. Limite : il faut prendre le temps de tout configurer, et les sites livrés « clé en main » par des prestataires bon marché arrivent quasi systématiquement avec la moitié des réglages absents. À vérifier dès qu’on récupère la main sur une installation existante.