Sécuriser un site WordPress : le guide opérationnel pour freelances et agences

Diagnostic externe, durcissement, surveillance et reporting client : une méthode structurée pour fiabiliser un parc de sites WordPress et transformer la sécurité en argument commercial.

Un client appelle un lundi matin, sa boutique WordPress redirige vers un casino en ligne. Trois jours plus tard, Google a blacklisté le domaine et le chiffre d'affaires est à zéro. Ce scénario se rejoue chaque semaine chez les agences qui gèrent des parcs de sites clients, et la cause est presque toujours la même : un plugin obsolète, un mot de passe trop simple, une page de connexion exposée à des milliers de tentatives par heure.

Sécuriser un site WordPress ne consiste pas à empiler des plugins de sécurité jusqu'à ce que le tableau de bord devienne illisible. C'est une démarche structurée qui commence par un diagnostic externe, se prolonge par un durcissement de la configuration et se termine par une surveillance continue. Cet article détaille les étapes concrètes que vous pouvez appliquer dès aujourd'hui, dans la perspective d'un freelance ou d'une agence qui veut fiabiliser ses sites clients et transformer chaque audit en argument commercial.

Pourquoi WordPress concentre autant d'attaques

La popularité comme facteur d'exposition

WordPress alimente une part dominante du web. Selon W3Techs, 43 % des sites mondiaux tournent sous ce CMS, ce qui en fait mécaniquement la première cible des attaquants. Les robots ne ciblent pas un site précis, ils balayent en permanence toutes les adresses IP du web à la recherche de signatures WordPress connues.

Quand une faille est publiée pour un plugin populaire, des milliers de sites peuvent être compromis dans les heures qui suivent. La logique est purement statistique : un attaquant qui maîtrise une faille sur un plugin présent sur cent mille sites maximise son retour sur investissement. C'est ce qui rend la posture de sécurité critique, même pour un site vitrine de TPE qui se croit invisible.

Les vecteurs d'attaque les plus fréquents

Les principales portes d'entrée d'un site WordPress sont connues et documentées. Les attaques par force brute sur la page de connexion arrivent en tête, suivies par les vulnérabilités de plugins non mis à jour, les thèmes nulled téléchargés sur des sites pirates, et les configurations laxistes côté serveur.

S'ajoutent à cela les fichiers exposés qui ne devraient jamais être publics : le fichier readme.html qui révèle la version de WordPress, le répertoire /wp-content/uploads/ qui permet la navigation libre des dossiers, ou encore le point d'entrée XML-RPC qui sert régulièrement de levier d'amplification pour les attaques. Un audit externe correctement mené détecte ces vecteurs structurels en quelques secondes.

Le coût d'un piratage pour une agence

Au-delà du dommage technique, un piratage coûte du temps de remédiation, de la réputation et parfois des clients. Une intervention d'urgence sur un site compromis se facture entre 500 et 2 000 euros selon l'ampleur du nettoyage, et n'inclut pas le préjudice pour le client final. À l'inverse, un contrat de maintenance mensuel à 100 ou 150 euros qui inclut surveillance et mises à jour reste plus rentable pour les deux parties.

Diagnostic externe : ce qu'un audit révèle sans accès admin

Les informations exposées par défaut

Une installation WordPress standard expose par défaut un nombre surprenant d'informations. La version du CMS apparaît dans le code source via la balise generator, dans le fichier readme.html, et parfois dans les en-têtes de réponse HTTP. Cette information permet à un attaquant de cibler les failles connues de cette version précise.

Les noms d'utilisateurs administrateurs sont également exposés via l'API REST de WordPress sur l'endpoint /wp-json/wp/v2/users, ainsi que via les paramètres ?author=1, ?author=2, etc. Un robot qui collecte ces noms peut ensuite lancer des attaques ciblées au lieu de tester des identifiants au hasard.

Le scan des dossiers et fichiers sensibles

Un audit externe vérifie systématiquement la présence de fichiers qui ne devraient jamais être publics. Le fichier wp-config.php.bak, parfois oublié après une intervention manuelle, contient les identifiants de la base de données. Le dossier /wp-content/debug.log peut révéler des chemins serveur et des erreurs PHP. La navigation libre des dossiers sur /wp-includes/ ou /wp-content/uploads/ permet à un attaquant de cartographier l'installation.

Dans les audits réalisés avec Orilyt, nous constatons régulièrement que près d'un site WordPress sur deux laisse au moins un de ces fichiers accessible publiquement, sans que le propriétaire en ait conscience. La détection prend quelques secondes, la correction quelques minutes.

Les faiblesses de la page de connexion

L'URL /wp-login.php est connue de tous les robots. En une nuit, un site qui n'a aucune protection peut subir plusieurs milliers de tentatives de connexion par force brute. Les serveurs mutualisés finissent parfois par afficher des erreurs 500 simplement à cause de cette charge parasite.

Un audit externe peut détecter si la page de connexion est exposée publiquement, si elle est protégée par une limitation de tentatives, et si elle dispose d'un second facteur d'authentification. La méthodologie d'audit WordPress complet détaille la grille d'analyse appliquée à ce CMS et les tests spécifiques activés sur cette plateforme.

Durcir la configuration : les actions à fort impact

Les mises à jour comme priorité absolue

La règle est simple : un plugin, un thème ou un cœur WordPress non mis à jour est une faille en attente d'exploitation. Les patchs publiés par WordPress et la communauté corrigent en permanence des vulnérabilités, parfois critiques. Un plugin abandonné depuis plus de douze mois par son développeur doit être considéré comme dangereux et remplacé.

Les mises à jour automatiques du cœur WordPress sont activées par défaut depuis la version 5.6 pour les versions mineures. Étendre cette logique aux plugins critiques via les options du tableau de bord, ou via une ligne dans wp-config.php, réduit drastiquement la fenêtre d'exposition. La mise à jour automatique des plugins n'est pas sans risque (incompatibilités possibles), mais l'inverse est statistiquement pire.

Les mots de passe et l'authentification

Un mot de passe administrateur de moins de douze caractères, sans majuscules ni chiffres ni caractères spéciaux, est cassable en quelques minutes par un script standard. La règle minimale est de seize caractères, idéalement générés par un gestionnaire comme Bitwarden ou 1Password. Le gestionnaire de mots de passe est un outil professionnel non négociable pour quiconque gère plus de trois sites.

L'authentification à double facteur (2FA) ajoute une couche défensive très efficace. Activée via un plugin léger comme Two Factor ou Wordfence Login Security, elle bloque la quasi-totalité des attaques par force brute, même si le mot de passe finit par être compromis ailleurs.

Les permissions de fichiers et la base de données

Les permissions Unix correctes pour un site WordPress sont 644 pour les fichiers et 755 pour les dossiers. Le fichier wp-config.php doit être en 600 ou 640 pour limiter l'accès aux seules entités du serveur. Une configuration laxiste des permissions, comme un 777 hérité d'une migration ratée, ouvre la porte à la modification arbitraire des fichiers PHP par un script malveillant.

Côté base de données, le préfixe par défaut wp_ est connu de tous les attaquants et facilite les injections SQL ciblées. Le changer pour un préfixe aléatoire au moment de l'installation, ou via un plugin de migration ensuite, complique le travail des scripts automatisés sans impact sur les performances.

Les sauvegardes comme filet de sécurité

Aucune sécurité n'est parfaite, et la sauvegarde régulière reste le dernier rempart. Une stratégie 3-2-1 reste la référence : trois copies des données, sur deux supports différents, dont une copie hors site. Les hébergeurs sérieux proposent des sauvegardes automatiques quotidiennes, mais une sauvegarde indépendante stockée chez un autre prestataire (S3, Backblaze, OVH Object Storage) est une assurance contre les compromissions de l'hébergeur lui-même.

UpdraftPlus, BackWPup ou Duplicator sont les plugins de référence pour automatiser ce type de sauvegarde. Leur configuration prend dix minutes et peut sauver une journée de travail le jour où un client appelle paniqué.

La couche réseau : en-têtes HTTP et HTTPS

HTTPS et redirection systématique

Un site sans HTTPS en 2026 est inacceptable. Au-delà du chiffrement des échanges, l'absence de certificat SSL valide déclenche un avertissement Chrome qui fait fuir les visiteurs. Tous les hébergeurs proposent désormais Let's Encrypt gratuitement, et la mise en place prend cinq minutes via cPanel ou un panneau équivalent.

La redirection systématique de HTTP vers HTTPS doit être configurée au niveau du serveur (htaccess pour Apache, configuration nginx) et non uniquement via WordPress. Un fichier .htaccess mal configuré laisse parfois la version HTTP accessible sur certaines URLs, ce qui expose les cookies de session aux attaques de type sslstrip.

Les en-têtes de sécurité HTTP

Les en-têtes de sécurité HTTP sont une couche défensive sous-utilisée. Strict-Transport-Security (HSTS) force le navigateur à utiliser HTTPS pour toutes les requêtes futures, même si l'utilisateur tape une URL en HTTP. Content-Security-Policy (CSP) limite les sources de scripts autorisées et bloque les injections XSS. X-Frame-Options empêche l'inclusion du site dans une iframe externe, protégeant contre les attaques de clickjacking.

Pour une analyse détaillée de chaque en-tête et des valeurs recommandées sur Apache et nginx, l'article dédié aux en-têtes de sécurité HTTP couvre la configuration concrète et les pièges classiques de mise en production.

Le pare-feu applicatif et le CDN

Un pare-feu applicatif web (WAF) filtre les requêtes malveillantes avant qu'elles n'atteignent WordPress. Cloudflare propose un WAF gratuit dans son offre de base, suffisant pour bloquer la majorité des attaques automatisées. Sucuri et Wordfence proposent des WAF plus spécialisés WordPress, avec des règles dédiées aux vulnérabilités courantes du CMS.

L'avantage secondaire du CDN est la mise en cache statique qui absorbe les pics de trafic, y compris les pics malveillants. Un site protégé par Cloudflare reste accessible même pendant une tentative d'attaque DDoS modérée, ce qui est un argument commercial concret pour un client e-commerce.

Surveillance continue et détection

Les logs et la détection d'anomalies

Une fois le site durci, la surveillance prend le relais. Les logs serveur révèlent les tentatives d'intrusion, les erreurs PHP suspectes, les accès à des fichiers qui ne devraient pas exister. Sur un hébergement mutualisé, l'accès aux logs passe généralement par cPanel ou par un panneau équivalent. Sur un VPS, les fichiers /var/log/apache2/access.log et error.log se consultent en SSH.

Un plugin comme WP Activity Log enregistre toutes les actions effectuées dans le tableau de bord WordPress (création d'utilisateur, modification de fichier, installation de plugin) et permet de détecter une activité suspecte rapidement. C'est particulièrement utile pour les sites multi-utilisateurs où plusieurs personnes ont des accès administrateur.

Les alertes automatisées

La surveillance manuelle ne fonctionne pas à l'échelle d'un parc de plusieurs sites clients. Mettre en place des alertes automatisées sur les changements critiques (certificat SSL qui expire, version WordPress obsolète, plugin vulnérable, page de connexion qui se met à recevoir un volume anormal de tentatives) est la seule approche industrialisable.

Orilyt génère des alertes mensuelles sur l'évolution de la posture de sécurité de chaque site sous monitoring, avec un rapport client lisible qui résume les points résolus, les points en cours et les recommandations pour le mois suivant. Cette automatisation libère le freelance ou l'agence du suivi quotidien manuel.

La vérification post-incident

Si un site a été compromis, la procédure ne s'arrête pas au nettoyage. Il faut vérifier que tous les utilisateurs administrateurs sont légitimes, régénérer les clés SALT dans wp-config.php, changer tous les mots de passe (WordPress, FTP, base de données, hébergeur), et scanner intégralement le site. Une vérification post-incident complète prend en général quatre à huit heures et doit être documentée pour le client.

Transformer la sécurisation en argument commercial

Le rapport client comme outil de vente

Un audit qui se traduit par un PDF illisible plein de jargon ne génère ni confiance ni signature. Le rapport client lisible, structuré en faits, impacts et actions, est ce qui permet de transformer une recommandation technique en décision business. Un client qui comprend que son fichier readme.html expose la version de WordPress et ce que cela implique concrètement signe plus facilement un devis de remédiation.

Pour creuser la conversion d'un audit en mission récurrente, le contrat de maintenance WordPress détaille les clauses à intégrer pour structurer une offre rentable et défendable face au client.

Le devis automatique à partir de l'audit

Le passage de l'audit au devis est souvent l'étape qui fait perdre le plus de temps. Chaque test en échec doit être traduit en ligne de prestation compréhensible par un décideur, avec un effort estimé et un prix. Un devis automatique généré directement depuis le rapport d'audit réduit ce délai à quelques minutes au lieu de plusieurs heures, et c'est le ressort principal pour transformer un audit en contrat de maintenance sans laisser refroidir le prospect.

C'est la différence entre une agence qui ferme un dossier sécurité en 24 heures et une qui laisse traîner une semaine, le temps que le client signe ailleurs. La rapidité de réponse est un facteur de conversion documenté dans la vente B2B.

Le suivi mensuel et la rétention

Une fois le contrat signé, le rapport mensuel automatique justifie la facturation récurrente. Un client qui paie 150 euros par mois sans jamais voir de livrable finit par remettre en cause la dépense. À l'inverse, un rapport qui montre les mises à jour appliquées, les sauvegardes vérifiées et les alertes traitées rend la valeur tangible et facilite le renouvellement.

Cette logique de rétention est le multiplicateur principal d'une activité de maintenance. Un client conservé deux ans rapporte largement plus qu'un nouveau client signé chaque trimestre, et le coût d'acquisition est nul. Pour estimer le bon plan en fonction de votre portefeuille, comparez les tarifs Orilyt en regard du volume de sites que vous gérez.

La sécurisation d'un site WordPress n'est pas un projet ponctuel mais un processus continu qui combine durcissement initial, surveillance et reporting. Un freelance ou une agence qui structure cette démarche sur l'ensemble de son portefeuille gagne en crédibilité face aux clients, en rentabilité grâce à la maintenance récurrente, et en sérénité grâce à la détection précoce des incidents.

L'audit externe en lecture seule reste la porte d'entrée la plus simple pour démarrer. Il ne demande aucun accès admin, aucune installation, aucun risque pour le site, et fournit en quelques minutes la cartographie complète des points à corriger. C'est aussi la base d'une conversation commerciale honnête avec un prospect qui ne vous connaît pas encore.

Vos questions les plus fréquentes

Sources et références

• W3Techs, Usage Statistics of Content Management Systems — statistiques de parts de marché des CMS dans le monde.
• OWASP, WordPress Security Implementation Guideline — référentiel de bonnes pratiques sécurité WordPress.
• MDN Web Docs, HTTP Strict Transport Security — documentation officielle de l'en-tête HSTS.
• CNIL, Sécurité des sites web — recommandations sécurité de la CNIL pour les sites web.
• Cloudflare Blog, Web Application Firewall — articles techniques sur les pare-feu applicatifs web.