Durcir WordPress : protéger le site d’une PME en dix chantiers

Votre PME, votre cabinet ou votre OBNL tourne sur WordPress et vous préférez agir avant qu’un incident vous force la main? Le durcissement de WordPress regroupe les réglages qui rétrécissent la surface d’attaque : on retire les droits inutiles, on cache les fichiers sensibles et on garde des traces exploitables. Ce guide établit les priorités et précise ce qui relève de vous et ce qui relève de votre hébergeur.

Référenceur est une agence de marketing numérique francophone dont les bureaux se trouvent en Belgique et au Luxembourg. Nous n’avons aucun bureau au Québec : nous accompagnons à distance, en visioconférence, les entreprises qui veulent auditer puis renforcer leur installation WordPress, en lien avec leur hébergeur.

Pour obtenir un premier portrait de votre site, lancez gratuitement l’outil d’analyse de sécurité ci-dessous.

Une condition passe avant tout le reste : un site déjà infecté doit être nettoyé avant d’être verrouillé. Vous voyez des redirections bizarres, des pages truffées de caractères asiatiques ou un administrateur que personne ne connaît? Faites d’abord retirer le code malveillant en conservant les preuves; notre page sur le dépannage d’un site WordPress piraté décrit cette étape. Vous reviendrez ensuite à ce guide pour fermer les accès.

Que veut dire « durcir » un site WordPress?

Les mises à jour bouchent les failles déjà connues. Le durcissement, lui, limite les dommages dans les autres cas : une faille pas encore corrigée, un mot de passe qui a circulé, une extension que son auteur a laissée tomber.

La documentation officielle Hardening WordPress classe ces mesures par niveaux : serveur, base de données, système de fichiers, comptes utilisateurs et journalisation. Nous l’appliquons aux sites qu’on croise le plus souvent dans les PME : vitrine de travailleur autonome, réservations de restaurant, boutique WooCommerce, site bilingue français-anglais.

Si votre organisation recueille des renseignements personnels par des formulaires ou des comptes clients, ces réglages s’inscrivent aussi dans les mesures de sécurité « raisonnables » qu’exigent la Loi 25 au Québec et, selon vos activités, la LPRPDE fédérale.

Avant de toucher à quoi que ce soit : trois précautions

Première précaution, une sauvegarde complète vérifiée : les fichiers et la base de données, rangés ailleurs que sur le serveur, et dont vous avez déjà testé la restauration.

Deuxième précaution, un environnement de préproduction quand votre hébergement en offre un : une permission trop stricte ou un en-tête mal réglé suffit à bloquer un formulaire de réservation ou le paiement d’une commande. Troisième précaution, la liste des accès : qui détient un compte administrateur, un accès SFTP, un accès à la base de données ou au panneau de l’hébergeur?

Dix chantiers, du plus urgent au plus pointu

Suivez cet ordre : on commence par les risques qu’on rencontre tous les jours et on termine par les réglages plus spécialisés.

1. HTTPS partout : un certificat valide, une redirection 301 du HTTP vers le HTTPS et des adresses en https dans Réglages > Général. La constante FORCE_SSL_ADMIN oblige le chiffrement pour la connexion et le tableau de bord.
2. Des permissions de fichiers sensées : 755 pour les dossiers, 644 pour les fichiers, selon la recommandation de WordPress, et wp-config.php en 440 ou 400 si l’hébergeur l’autorise.
3. L’éditeur de code désactivé grâce à DISALLOW_FILE_EDIT : si un compte administrateur est volé, il ne pourra plus servir à modifier les thèmes et les extensions depuis le tableau de bord.
4. De nouvelles clés et de nouveaux sels après chaque incident ou chaque départ de fournisseur : les sessions ouvertes (et leurs témoins) cessent d’être valides et tout le monde doit se reconnecter.
5. L’authentification à deux facteurs pour chaque administrateur et chaque gestionnaire de boutique. WordPress ne l’intègre pas d’office : il faut une extension reconnue ou un fournisseur d’identité.
6. Un plafond de tentatives de connexion sur wp-login.php, de préférence appliqué par le serveur ou le pare-feu, et xmlrpc.php fermé si aucune application n’en a besoin.
7. Un pare-feu applicatif Web (WAF), placé en amont du site ou intégré au serveur, qui écarte les requêtes malveillantes avant qu’elles atteignent WordPress.
8. Des en-têtes de sécurité HTTP : HSTS, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, puis une politique CSP bâtie par étapes.
9. Un bon ménage : les thèmes et extensions inutilisés sont supprimés, pas seulement désactivés; l’affichage des erreurs est coupé en production; les comptes des anciens fournisseurs sont fermés.
10. Des traces : journaux d’accès et d’erreurs conservés, alerte dès qu’un administrateur est créé, vérification périodique de l’intégrité des fichiers.

Une partie des chantiers 1, 3 et 9 se règle dans wp-config.php, en ajoutant ces lignes au-dessus du commentaire « That’s all, stop editing! » :

define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

La constante DISALLOW_FILE_MODS est plus radicale : elle empêche aussi d’installer ou de mettre à jour des extensions depuis l’administration. Gardez-la pour les sites dont les mises à jour passent par WP-CLI ou par un déploiement automatisé, sinon plus personne ne pourra appliquer les correctifs.

Connexions, pare-feu et en-têtes : là où il faut doser

Pour les en-têtes, la fiche OWASP sur les en-têtes HTTP fait autorité. Elle recommande nosniff, une politique de référent strict-origin-when-cross-origin et la directive CSP frame-ancestors, qui empêche un site tiers d’afficher vos pages dans un cadre. Elle déconseille en revanche de compter sur le vieil en-tête X-XSS-Protection.

HSTS se manie avec soin. Dès qu’un navigateur reçoit cet en-tête, il refuse toute connexion en HTTP pendant la période indiquée. Ne l’activez que lorsque tout le domaine répond en HTTPS, y compris les sous-domaines si vous ajoutez includeSubDomains.

Côté connexions, la documentation de WordPress sur les attaques par force brute recommande de filtrer le plus près possible du réseau : une extension PHP, elle, consomme des ressources du serveur à chaque tentative qu’elle bloque.

Les questions à poser à votre hébergeur

Une bonne part du durcissement se joue hors de WordPress. D’abord, la version de PHP. Selon le calendrier publié sur php.net, les branches 8.4 et 8.5 profitent encore du support actif, la 8.3 ne reçoit plus que des correctifs de sécurité et la 8.2 arrive en fin de vie le 31 décembre 2026. Si votre site fonctionne encore en 8.2 ou dans une version plus ancienne, planifiez la migration sans tarder, après un essai en préproduction.

Ensuite, le cloisonnement : chaque site devrait avoir son propre utilisateur système, sa propre base et ses propres identifiants. Quand cinq sites partagent un seul compte FTP, chacun devient une porte d’entrée vers les quatre autres.

Enfin, les accès et les copies : SFTP plutôt que FTP, utilisateur de base de données aux droits limités, sauvegardes stockées hors du serveur et accès à vos journaux. Le lieu d’hébergement compte aussi : si des renseignements personnels sont conservés à l’extérieur du Québec, la Loi 25 exige une évaluation des facteurs relatifs à la vie privée avant de les communiquer hors du Québec. Demandez les réponses par écrit. Ce guide n’est pas un avis juridique.

Qui fait quoi : le tableau de partage

Volet	Ce que vous pouvez faire vous-même	Ce que l’hébergeur ou le fournisseur doit assurer
HTTPS et HSTS	Vérifier que les adresses sont en https dans Réglages > Général	Renouvellement du certificat, redirection 301, HSTS activé prudemment
wp-config.php et fichiers	Ajouter DISALLOW_FILE_EDIT, régénérer les clés	Droits 755/644, wp-config.php en 440 ou 400
Comptes	Retirer les comptes inactifs, activer l’authentification à deux facteurs	Couper les accès SFTP et base de données des anciens intervenants
Connexion et pare-feu	Mots de passe longs conservés dans un gestionnaire	Limitation sur wp-login.php, WAF, xmlrpc.php désactivé
Serveur et PHP	Noter la version affichée dans Outils > Santé du site	Branche de PHP maintenue, isolement de chaque site
Journaux et copies	Faire un essai de restauration sur une copie	Journaux conservés, sauvegardes hors serveur

Ayez ce tableau sous les yeux à votre prochaine discussion avec l’hébergeur. Chaque ligne réglée vous rend moins dépendant d’un seul intervenant.

Détecter une intrusion avant vos clients

Même verrouillé, un site n’est jamais à l’abri. Ce qui compte, c’est d’apprendre rapidement qu’un élément a changé. Si votre hébergeur donne accès à WP-CLI, ces commandes officielles comparent vos fichiers aux versions publiées et affichent la liste des administrateurs :

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator

Un fichier du cœur modifié, un administrateur que vous ne reconnaissez pas ou un fichier PHP caché dans wp-content/uploads justifient une vérification immédiate. Branchez aussi la Google Search Console pour recevoir ses alertes de sécurité, et servez-vous de l’outil d’analyse gratuit de cette page comme premier contrôle vu de l’extérieur.

Les faux pas qui défont tout le travail

Le plus coûteux : installer un thème ou une extension « nulled », c’est-à-dire une version payante piratée pour se passer de licence. Ce code trafiqué renferme souvent la porte dérobée que vous essayez justement de fermer.

Autres erreurs fréquentes : remettre en ligne une sauvegarde déjà contaminée, ou transmettre des mots de passe par courriel sans jamais les changer par la suite. Le durcissement ne tient que s’il s’accompagne d’un entretien régulier : mises à jour, revue des comptes, essai de restauration et lecture des journaux.

Un accompagnement mené entièrement à distance

Pas besoin de se déplacer pour durcir un site, et c’est tant mieux. Une première rencontre en visioconférence permet de faire l’inventaire des extensions, des comptes et de l’hébergement. Chaque réglage est ensuite appliqué en partage d’écran, devant vous, à une heure qui convient aux deux fuseaux horaires.

Vous gardez le contrôle : nous travaillons avec un compte nominatif temporaire, puis une formation enregistrée et un suivi mensuel prennent le relais. La formule vaut autant pour un commerce de quartier que pour un bureau de comptables ou un OBNL. Si vous préparez un nouveau site, notre équipe de création de sites Web part d’une base propre dès le départ.

Durcissement WordPress : questions courantes

Mon hébergeur ne s’occupe-t-il pas déjà de la sécurité?

Seulement d’une partie. L’hébergeur protège ses serveurs, mais vos extensions, vos comptes et vos mots de passe demeurent votre responsabilité. Faites-lui préciser par écrit ce que son forfait comprend : isolement, sauvegardes, pare-feu, journaux. Le reste se planifie avec votre fournisseur Web, à l’aide du tableau ci-dessus.

Un site bilingue est-il plus difficile à protéger?

Pas en soi, mais il compte souvent plus d’extensions (traduction, formulaires propres à chaque langue) et plus d’utilisateurs. Chaque extension de plus doit être entretenue, et chaque traducteur doit avoir son propre compte, avec un rôle limité. Assurez-vous aussi que tous les domaines et sous-domaines linguistiques répondent en HTTPS avant d’activer HSTS.

DISALLOW_FILE_EDIT suffit-il à arrêter un pirate?

Non. Cette constante ne ferme qu’une porte, celle de l’édition du code depuis le tableau de bord. Une extension vulnérable permet toujours de déposer un fichier malveillant. Elle complète les mises à jour, l’authentification à deux facteurs, le pare-feu applicatif et le contrôle d’intégrité; elle ne les remplace jamais.

La Loi 25 m’oblige-t-elle à durcir mon site?

La Loi 25 ne dresse pas de liste de réglages WordPress. Elle demande plutôt aux entreprises de prendre des mesures de sécurité raisonnables, compte tenu de la sensibilité des renseignements qu’elles détiennent. Un site doté de formulaires, d’inscriptions ou de comptes clients est donc concerné. En cas d’incident de confidentialité, la Commission d’accès à l’information (CAI) doit être avisée s’il y a un risque de préjudice sérieux. Ce guide n’est pas un avis juridique : validez votre situation auprès d’un juriste.

Faut-il changer l’adresse de connexion wp-admin?

Modifier l’adresse de connexion diminue le bruit des robots, sans être une vraie protection. WordPress mise plutôt sur la limitation des tentatives côté serveur, sur des mots de passe longs et sur l’authentification à deux facteurs. Si vous changez quand même l’adresse, notez-la dans votre gestionnaire de mots de passe pour ne pas bloquer votre propre équipe.

Une boutique WooCommerce demande-t-elle plus de précautions?

Oui, puisqu’elle conserve des adresses, des commandes et des comptes clients. Activez l’authentification à deux facteurs pour chaque gestionnaire, réservez le rôle « Gestionnaire de boutique » à ceux qui en ont vraiment besoin, gardez les journaux et tenez les extensions de paiement à jour. Revoyez la configuration chaque fois qu’un module s’ajoute.

À quelle fréquence revoir la configuration?

Pour la plupart des PME et des travailleurs autonomes, une revue mensuelle suffit : mises à jour, comptes, journaux et essai de restauration. Refaites l’exercice après tout changement d’hébergeur ou de fournisseur. Quand un site est trop vieux pour être assaini, le reconstruire sur une base saine est parfois plus sûr que d’empiler les correctifs.

Un doute sur l’état de votre site? Lancez une analyse de sécurité gratuite de votre site WordPress :

Référenceur, agence de marketing numérique francophone de Belgique et du Luxembourg, aide à distance les entreprises québécoises à verrouiller leur WordPress. Obtenir un diagnostic gratuit : en partage d’écran, nous examinons votre installation avec vous et classons les réglages de durcissement à faire en premier.