Comment sécuriser un site WordPress contre les attaques : le guide essentiel

Un client m'appelle un mardi matin, paniqué. Son site affiche une page blanche avec un message en cyrillique. Il a pourtant un certificat SSL, un mot de passe de 16 caractères, et il met à jour ses extensions "de temps en temps". Trois heures plus tard, je trouve la porte d'entrée : un plugin de formulaire abandonné depuis quatorze mois, avec une faille de type injection SQL que personne n'avait signalée. Le SSL, lui, n'a rien empêché du tout.

C'est la première chose à comprendre quand on cherche comment sécuriser un site WordPress contre les attaques : la sécurité n'est pas une case à cocher, c'est une chaîne. Un attaquant n'a pas besoin de forcer toutes les serrures. Il lui suffit d'en trouver une seule qui ferme mal.

Comprendre la chaîne d'attaque avant de poser le moindre correctif

Je vois souvent des listes de "10 astuces" empilées sans logique. Le problème, c'est qu'appliquer des mesures au hasard donne un faux sentiment de sécurité. Mieux vaut comprendre l'ordre dans lequel un attaquant travaille.

Le déroulé typique, étape par étape

Une campagne automatisée ressemble rarement à un film de hacker. C'est monotone et industriel. D'abord la reconnaissance : un scanner parcourt le web à la recherche de signatures WordPress (le fichier wp-login.php, le fichier readme.html, la balise meta du générateur dans le code source). Ensuite, l'identification des versions : de quel plugin s'agit-il, dans quelle version ? Puis l'exploitation d'une vulnérabilité publique. Enfin, on installe une porte dérobée discrète, on crée un compte administrateur fantôme, on reste. Et souvent, on ne fait rien tout de suite : la persistance silencieuse vaut mieux qu'un défigement bruyant.

Chaque étape ci-dessus peut être cassée. Retirer la signature de version. Ne pas exposer un fichier lisible par tous. Fermer la faille avant qu'elle ne serve. Détecter la porte dérobée avant qu'elle ne s'active. Voilà la logique réelle.

Pourquoi activer HTTPS ne sécurise pas votre site pour autant

Question qu'on me pose sans arrêt : "j'ai activé le SSL chez mon hébergeur, donc je suis protégé, non ?" Non. Le certificat SSL chiffre la communication entre le navigateur et le serveur. Il empêche l'interception du trafic en clair. Il ne vérifie jamais si le visiteur a le droit d'écrire dans votre base de données. Il ne bloque pas une injection SQL. Il ne vérifie pas les permissions d'un fichier. C'est un tunnel, pas un videur.

Un site peut donc afficher un joli cadenas vert et se faire vider sa base en une nuit. Le SSL est nécessaire, oui. Il est loin d'être suffisant.

Durcir les accès : le levier le plus rentable

Si je devais ne garder qu'une seule famille de mesures, ce serait celle-ci. C'est là que le rapport effort/résultat est le meilleur.

Protéger la page de connexion et activer la double authentification

La page wp-login.php est martelée en permanence par des bots qui essaient des combinaisons de mots de passe. Trois réglages changent tout :

• Limiter le nombre de tentatives (typiquement cinq, puis blocage temporaire de l'adresse IP).
• Ajouter un CAPTCHA sur le formulaire de connexion pour casser l'automatisation.
• Activer la double authentification (2FA) : même si le mot de passe fuite, le code temporaire bloque l'accès.

Une extension comme Wordfence couvre ces trois points sans configuration compliquée. Je l'ai installée sur un blog perso après avoir vu passer des milliers de tentatives de connexion en deux jours. Le nombre d'échecs a chuté, mais surtout, j'ai enfin eu une visibilité sur ce qui se passait. Avouons-le : sans journalisation, on pilote à l'aveugle.

Faut-il masquer la page d'administration ?

Des outils comme Hide My WP permettent de changer l'URL de connexion, de renommer les chemins, de brouiller les signatures. Franchement, ça aide : un bot qui cherche /wp-admin ne trouve rien et passe son chemin vers un site plus facile. Mais ce n'est pas une protection en soi. C'est de l'obscurité utile, pas un verrou. Je le recommande en complément, jamais en remplacement du durcissement réel.

La supply chain : le vrai point faible de WordPress

Rappelons un fait connu : le cœur de WordPress est maintenu par une équipe dédiée et se met à jour tout seul sur la majorité des installations. Ce ne sont donc pas tellement les failles du CMS qui font tomber les sites. Ce sont les extensions et les thèmes.

Une extension abandonnée par son auteur reste installée pendant des années. Personne ne la corrige. Sa faille devient publique. Et les scanners la cherchent activement. J'ai vu un site tomber à cause d'un plugin de galerie photo qui n'avait pas reçu une seule mise à jour depuis plus de deux ans.

Comment auditer une extension avant de l'installer

Avant de cliquer sur "Installer", je regarde systématiquement quatre signaux :

1. La date de la dernière mise à jour. Plus de six mois sans rien, méfiance.
2. Le nombre d'installations actives. Un plugin utilisé par des milliers de sites bénéficie d'une surveillance collective.
3. Les avis récents et le support de l'auteur. Un fil de support déserté est un mauvais signe.
4. Le nombre de vulnérabilités connues dans son historique. Certains plugins traînent une réputation.

Règle simple que j'applique : moins d'extensions, mieux entretenues. Chaque plugin supplémentaire est une porte supplémentaire. Les thèmes "nulled" ou piratés, eux, sont à bannir absolument : ils embarquent très souvent du code malveillant ajouté volontairement.

Le durcissement serveur, souvent oublié

Beaucoup de guides s'arrêtent à WordPress et ignorent le serveur. C'est une erreur, parce que certaines protections les plus efficaces s'y trouvent.

Désactiver l'exécution de PHP dans le dossier des médias

Le dossier /wp-content/uploads/ est fait pour recevoir des images. Aucun fichier PHP n'a de raison d'y être exécuté. Pourtant, de nombreux webshells y sont déposés sous forme de fichier .php déguisé. Une simple règle serveur qui interdit l'exécution de PHP dans ce répertoire casse net cette technique. C'est une ligne de configuration, pour un gain considérable.

Pare-feu applicatif et en-têtes de sécurité

Un WAF (pare-feu applicatif web) filtre les requêtes malveillantes avant qu'elles n'atteignent WordPress. Certains hébergeurs l'incluent, d'autres le proposent en option. Du côté des en-têtes HTTP, HSTS force le navigateur à n'utiliser que HTTPS, et une politique de sécurité de contenu (CSP) limite l'exécution de scripts non autorisés. Ce sont des réglages de serveur, pas de WordPress, mais ils font partie de la même chaîne.

Détection et réponse : ce qu'on fait quand ça a déjà cassé

La question que personne ne pose dans les listes d'astuces : et si le site est déjà compromis ?

Surveiller l'intégrité des fichiers

Un bon outil de sécurité compare régulièrement l'empreinte des fichiers de votre site à une référence. Toute modification inattendue déclenche une alerte. C'est ainsi qu'on détecte une backdoor ajoutée dans un fichier légitime, ou un fichier nouveau apparu dans un coin du dossier des médias. Sans ce contrôle, un site peut être infecté pendant des mois en toute discrétion.

Que faire après une compromission

Dans l'ordre : mettre le site hors ligne, changer tous les mots de passe (base de données, comptes admin, accès FTP, hébergeur), supprimer les fichiers et extensions non identifiés, réinstaller une version propre du cœur et des extensions depuis les dépôts officiels, puis chercher les comptes administrateurs fantômes. Et vérifier les tâches planifiées (wp_cron) : les attaquants y cachent parfois des appels réguliers vers l'extérieur. La restauration d'une sauvegarde antérieure est souvent plus rapide et plus sûre que le nettoyage manuel, à condition que la sauvegarde soit antérieure à l'intrusion et stockée hors du serveur.

Mesure	Maillon cassé	Effort
Mises à jour automatiques	Exploitation d'une faille publique	Faible
2FA + limitation des tentatives	Force brute sur la connexion	Faible
Audit des extensions	Supply chain	Moyen
PHP désactivé dans /uploads	Exécution d'un webshell	Faible
Surveillance d'intégrité	Persistance silencieuse	Moyen
Sauvegardes hors serveur	Perte totale après compromission	Faible

Par quoi commencer concrètement

Si vous partez de zéro, ne cherchez pas à tout faire en une soirée. Voici mon ordre, du plus rentable au moins urgent.

• Mettre à jour le cœur, les thèmes et les extensions, et activer les mises à jour automatiques.
• Supprimer tout ce qui n'est pas utilisé : thèmes inactifs, extensions désactivées.
• Activer la 2FA et la limitation des tentatives sur la connexion.
• Configurer des sauvegardes automatiques, stockées ailleurs que sur le serveur.
• Désactiver l'exécution de PHP dans le dossier des médias et vérifier les permissions des fichiers.
• Ajouter une surveillance d'intégrité des fichiers.

Aucun de ces points ne rend votre site invulnérable, et quiconque vous promet le contraire vous vend quelque chose. La sécurité, c'est une question de coût : rendre l'attaque suffisamment pénible pour que l'attaquant aille voir ailleurs. La plupart des sites piratés ne le sont pas parce qu'ils étaient précieux, mais parce qu'ils étaient faciles. Ce qui laisse une idée simple en tête : votre meilleur investissement n'est pas un outil, c'est une habitude — celle de garder la chaîne fermée partout, en permanence.