Sécuriser site WordPress : le guide du durcissement pour PME suisses

Vous voulez sécuriser site WordPress après une alerte, ou avant que les ennuis ne commencent ? Le durcissement WordPress (le « hardening » des anglophones) consiste à réduire la surface d’attaque : moins de portes ouvertes, moins de droits inutiles, plus de traces exploitables. Ce guide détaille chaque mesure, ce que vous pouvez faire vous-même et ce qu’il faut demander à votre hébergeur.

L’agence Référenceur aide les PME de Suisse romande à durcir leur installation WordPress, de l’audit de configuration jusqu’à la maintenance mensuelle, entièrement en visioconférence et en lien direct avec leur hébergeur.

Analysez la sécurité de votre site WordPress : lancez dès maintenant une première analyse avec notre outil ci-dessous.

Un principe avant tout : on ne durcit pas un site encore infecté. Si vous voyez des redirections, des pages en japonais ou des comptes inconnus, commencez par nettoyer le malware en conservant les preuves ; le durcissement vient ensuite, pour empêcher la réinfection.

Pourquoi le durcissement WordPress complète les mises à jour

Les mises à jour corrigent les failles connues du cœur, des thèmes et des extensions. Le durcissement limite les dégâts quand une faille n’est pas encore corrigée, qu’un mot de passe a fuité ou qu’une extension est abandonnée par son auteur.

Les deux ne servent à rien sans sauvegardes externalisées et testées : c’est votre filet si une mesure casse le site ou si une attaque réussit malgré tout. Aucune configuration ne rend un site invulnérable ; l’objectif est de réduire le risque et de détecter vite.

La documentation officielle Hardening WordPress répartit d’ailleurs les mesures sur plusieurs niveaux : serveur, base de données, fichiers, comptes et journaux. C’est cette logique que nous suivons ci-dessous.

Sécuriser site WordPress : les 10 mesures dans l’ordre

Traitez les points dans cet ordre, après une sauvegarde complète (fichiers et base de données) et idéalement sur une copie de préproduction.

1. HTTPS partout : certificat valide, redirection permanente de HTTP vers HTTPS, adresses du site en https dans les Réglages. La constante FORCE_SSL_ADMIN garantit que mots de passe et cookies de l’administration ne circulent jamais en clair.
2. Permissions des fichiers : 755 pour les dossiers, 644 pour les fichiers, 400 ou 440 pour wp-config.php, selon la documentation officielle. Seul wp-content doit être inscriptible par le serveur web.
3. Éditeur de fichiers désactivé avec DISALLOW_FILE_EDIT : un compte administrateur volé ne peut plus modifier le code depuis le tableau de bord. Cela n’empêche pas l’envoi de fichiers malveillants par une autre faille.
4. Clés de sécurité régénérées après tout incident : changer les clés de wp-config.php invalide tous les cookies existants et force chaque utilisateur à se reconnecter.
5. Comptes et rôles : pas de compte nommé « admin », un compte nominatif par personne, le rôle minimal nécessaire, et la double authentification (2FA) pour tous les administrateurs. Le cœur de WordPress ne l’intègre pas : il faut une extension ou un fournisseur d’identité.
6. Limitation des connexions sur wp-login.php, de préférence au niveau du serveur ou du pare-feu plutôt qu’en PHP. Désactivez xmlrpc.php si aucune application ne l’utilise.
7. Pare-feu applicatif (WAF) : un service placé devant le site ou un module serveur filtre les requêtes malveillantes avant qu’elles n’atteignent WordPress.
8. En-têtes de sécurité HTTP : HSTS, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy et, à terme, une politique CSP.
9. Désactivation de l’inutile : extensions et thèmes inactifs supprimés (pas seulement désactivés), affichage des erreurs coupé en production, accès de prestataires clôturés.
10. Journalisation et surveillance : journaux d’accès et d’erreurs conservés, alertes sur les nouveaux administrateurs, vérification régulière de l’intégrité des fichiers.

Pour les points 1, 3 et 9, quelques lignes suffisent dans wp-config.php, à placer avant le 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 voisine DISALLOW_FILE_MODS va plus loin : elle bloque aussi l’installation et la mise à jour des extensions depuis l’administration. Ne l’activez que si les mises à jour sont gérées autrement, par exemple via WP-CLI ou un déploiement.

En-têtes HTTP, pare-feu et connexions : les réglages fins

Les recommandations de l’OWASP sur les en-têtes de sécurité sont une bonne base : nosniff, strict-origin-when-cross-origin pour le référent, et la directive CSP frame-ancestors pour interdire l’affichage du site dans un cadre. L’OWASP déconseille l’ancien en-tête X-XSS-Protection.

Prudence avec HSTS : une erreur de certificat peut alors bloquer vos visiteurs. Activez-le seulement quand tout le site, sous-domaines compris, fonctionne en HTTPS.

Côté connexions, la documentation WordPress sur les attaques par force brute recommande de limiter les tentatives au plus près du réseau (pare-feu, CDN ou serveur), car une extension PHP consomme des ressources pendant une attaque massive. Elle déconseille aussi les blocages permanents de pays entiers.

Hébergement et isolation : ce qui dépend de votre hébergeur

Une partie du durcissement se joue hors de WordPress. Commencez par la version de PHP : selon php.net, les branches 8.3, 8.4 et 8.5 sont supportées, et la 8.2 ne reçoit plus que des correctifs de sécurité jusqu’au 31 décembre 2026. Notre article sur la version PHP et la sécurité WordPress explique comment migrer sans casse.

Demandez ensuite une isolation par site : un utilisateur système, une base et des identifiants distincts pour chaque site. Dix sites dans le même compte FTP, c’est dix portes vers les neuf autres.

Exigez enfin SFTP plutôt que FTP, un utilisateur de base de données aux droits limités, des sauvegardes stockées hors du serveur et l’accès à vos journaux. Un hébergeur suisse sérieux sait répondre à ces questions par écrit.

Qui fait quoi : votre checklist de durcissement

Mesure	Ce que vous pouvez faire	À demander à l’hébergeur ou au prestataire
HTTPS et HSTS	Vérifier les adresses en https dans les Réglages	Certificat, redirection 301, activation prudente de HSTS
Fichiers et wp-config.php	Ajouter DISALLOW_FILE_EDIT, régénérer les clés	Permissions 755/644, wp-config.php en 400 ou 440
Comptes	Supprimer les comptes inutiles, activer la 2FA	Clôturer les accès SFTP et base des anciens prestataires
Connexions et WAF	Mots de passe longs dans un gestionnaire	Limitation sur wp-login.php, pare-feu applicatif, xmlrpc.php
PHP et isolation	Contrôler la version affichée dans Outils > Santé du site	Branche PHP supportée, un utilisateur système par site
Journaux et sauvegardes	Tester une restauration sur une copie	Conservation des journaux, sauvegardes hors serveur

Cette grille de durcissement WordPress tient sur une page : imprimez-la et cochez chaque ligne avec votre hébergeur.

Surveiller pour détecter tôt une intrusion

Pour sécuriser site WordPress dans la durée, il ne suffit pas de bloquer : il faut aussi être alerté rapidement. Si votre hébergement propose WP-CLI, ces commandes officielles comparent vos fichiers aux originaux et listent les administrateurs :

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

Un fichier modifié dans le cœur, un administrateur inconnu ou un fichier PHP dans wp-content/uploads sont des signaux d’alerte. Ajoutez la propriété du site dans la Search Console de Google pour recevoir les avertissements de sécurité.

Les erreurs qui annulent tous vos efforts

• Installer une extension ou un thème « nulled » (piraté) : c’est souvent la porte d’entrée elle-même.
• Durcir un site encore infecté, ou restaurer une sauvegarde qui contient déjà la porte dérobée.
• Changer le préfixe des tables ou les permissions en production sans sauvegarde testée.
• Envoyer des mots de passe par e-mail à chaque prestataire, puis ne jamais les changer.
• Activer DISALLOW_FILE_MODS et oublier que plus personne n’applique les mises à jour.

Le durcissement n’est jamais terminé : une maintenance continue combine mises à jour WordPress régulières, revue des comptes, test de restauration et contrôle des journaux.

Un durcissement piloté en visioconférence

Tout se fait à distance, et c’est un avantage : un atelier de cadrage en visio pour inventorier extensions, comptes et hébergement, puis des séances en partage d’écran où vous voyez chaque modification de wp-config.php ou du tableau de bord.

Vous gardez la maîtrise des accès : nous travaillons avec un compte nominatif temporaire, jamais avec vos identifiants personnels. Une formation enregistrée vous laisse la procédure, et un point mensuel suit la maintenance.

Le format est identique pour une PME de Lausanne, de Sion, de Neuchâtel ou du canton du Jura. Si le site a déjà été compromis, notre page site WordPress piraté décrit l’intervention, et le guide sécurité WordPress rassemble toute la série.

Sécuriser site WordPress : questions fréquentes

Un hébergeur suisse suffit-il à protéger mon site ?

Non : l’hébergeur protège le serveur, mais vos extensions, vos comptes et vos mots de passe restent sous votre responsabilité. Un hébergement en Suisse peut faciliter la conformité, sans remplacer le durcissement de l’installation elle-même. Demandez-lui par écrit ce qu’il couvre (isolation, sauvegardes, pare-feu, journaux) et organisez le reste avec votre prestataire.

Faut-il changer le préfixe wp_ des tables ?

La documentation officielle indique qu’un préfixe différent peut bloquer certaines injections SQL automatisées. Sur un site existant, l’opération touche la base et le fichier de configuration : elle demande une sauvegarde testée et une copie de préproduction. C’est une mesure secondaire, à traiter après les mises à jour, la 2FA et les permissions.

DISALLOW_FILE_EDIT suffit-il à empêcher un piratage ?

Non, il ferme une seule porte : la modification du code depuis le tableau de bord. Un attaquant peut encore exploiter une extension vulnérable pour déposer un fichier. Pour sécuriser site WordPress durablement, cette constante s’ajoute aux mises à jour, au pare-feu applicatif, à la double authentification et à la surveillance des fichiers, sans les remplacer.

Le durcissement a-t-il un lien avec la nLPD ?

La loi fédérale sur la protection des données demande des mesures techniques et organisationnelles appropriées au risque pour les données personnelles. Un site avec formulaires ou comptes clients est concerné. Ce guide ne constitue pas un avis juridique ; en cas d’incident, consultez notre page sur la fuite de données et la nLPD et les publications du PFPDT.

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

Oui, car elle stocke des adresses, des commandes et des comptes clients. Le durcissement WordPress y est prioritaire : 2FA pour tous les gestionnaires, pare-feu applicatif, journaux conservés et extensions de paiement maintenues à jour. Limitez aussi les rôles « Gestionnaire de boutique » aux personnes qui en ont réellement besoin.

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

Changer l’adresse de connexion réduit le bruit des robots, mais ce n’est pas une protection en soi. La documentation WordPress privilégie la limitation des tentatives au niveau du serveur ou du pare-feu, des mots de passe longs et la double authentification. Si vous masquez l’adresse, notez-la dans votre gestionnaire de mots de passe.

À quelle fréquence revoir la configuration ?

Une revue mensuelle convient à la plupart des PME : mises à jour, comptes, journaux, test de restauration. Revoyez aussi tout après un changement d’hébergeur, de prestataire ou une refonte. Si le site est trop ancien pour être assaini, une refonte de site WordPress est parfois plus sûre qu’un énième correctif.

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

Votre configuration WordPress vous inquiète ? Réservez un appel visio de 20 minutes : nous passons en revue votre installation en partage d’écran et listons les mesures de durcissement prioritaires.