Sécurité WordPress : 8 failles critiques et comment les corriger en 2026

Un lundi matin, un client m’appelle. Son site affiche une page en arabe depuis le week-end. Téléphone bombé, clients perdus, référencement saccagé. Cause : un plugin de cache non mis à jour depuis deux ans. On a tout repris en 48 heures. C’est ça le vrai coût d’une négligence à 0 CHF. Ce client avait quelque chose en commun avec la majorité des victimes que j’ai croisées en 25 ans de métier. On y revient à la fin.

La sécurité WordPress commence bien avant le premier incident. Elle débute au moment du choix de l’architecture de votre site et des composants installés dès le départ : thème, plugins, hébergeur. Sécuriser son installation WordPress est un réflexe que tout propriétaire de site peut adopter, technique ou pas. Ces choix initiaux définissent 80 % du niveau d’exposition futur, pas les réglages ajoutés après coup.

Pourquoi la sécurité WordPress est un problème de masse

WordPress alimente 43,2 % des sites du monde selon W3Techs (2025). Ce volume est une aubaine pour les développeurs. Du côté de la sécurité WordPress, c’est un signal d’alerte permanent : plus une plateforme est utilisée, plus elle devient rentable pour des attaques automatisées. Un script conçu pour WordPress peut toucher des millions de sites en parallèle, sans effort proportionnel pour l’attaquant.

WordPress est open source. Son code est lisible par tout le monde, y compris les personnes qui cherchent des failles. Dès qu’une vulnérabilité est détectée dans un plugin populaire, elle est publiée dans les bases CVE et exploitée dans les heures qui suivent. Le problème n’est pas WordPress en lui-même : c’est son écosystème de 60 000 plugins, dont une partie n’est plus maintenue. C’est là que les failles de sécurité WordPress les plus courantes prennent racine.

Franchement, le noyau WordPress est bien géré. L’équipe centrale corrige rapidement, et les mises à jour mineures sont automatiques depuis la version 3.7. Le danger vient d’ailleurs : plugins tiers non maintenus, thèmes achetés sur des sites pirates, configurations serveur négligées.

Failles de sécurité WordPress numéro 1 : plugins et thèmes obsolètes

Sécuriser WordPress commence par maîtriser son écosystème de plugins. 97 % des failles de sécurité WordPress passent par un plugin ou un thème mal maintenu. En janvier 2025, le plugin W3 Total Cache (version 2.8.1) présentait la vulnérabilité CVE-2024-12365 : un attaquant pouvait manipuler des requêtes côté serveur et accéder à des ressources sensibles. Plugin installé sur un million de sites. Correctif sorti en version 2.8.2. Ceux qui n’ont pas mis à jour ont été exposés pendant plusieurs semaines.

La même période a révélé CVE-2024-12240 dans Page Builder par SiteOrigin, permettant l’injection de scripts malveillants dans les pages. Deux plugins parmi les plus installés au monde, deux vulnérabilités en quelques semaines. Le correctif existait dans les deux cas. Le problème : l’administrateur qui ne l’avait pas appliqué.

Même logique pour les thèmes. Un thème téléchargé sur un site pirate contient souvent un backdoor intégré dès l’origine. L’attaquant accède alors au site à distance, sans craquer aucun mot de passe. D’ailleurs, la configuration initiale de WordPress, du choix du thème à la sélection des premiers plugins, conditionne tout ce qui suivra sur le plan de la sécurité WordPress.

Mots de passe faibles et comptes abandonnés

Les scripts de brute force testent des milliers de combinaisons par minute. « admin123 », « wordpress2025 », « 123456 » : premiers essais systématiques. En quelques secondes, un robot accède au tableau de bord et installe un malware en silence. Un mot de passe du type T!e92z@Ld#pQ9x rend cette attaque quasi impossible. L’activation de l’authentification à deux facteurs (2FA) l’élimine complètement.

Sécuriser les accès WordPress, c’est aussi sécuriser la gestion des rôles. La mauvaise attribution des permissions est un vecteur d’attaque régulier. Un ancien stagiaire toujours administrateur, un compte créé pour un prestataire extérieur jamais supprimé, un rôle éditeur donné par défaut au lieu de contributeur : chacun de ces oublis laisse une surface d’attaque ouverte. La règle du moindre privilège reste la meilleure défense : droits minimaux nécessaires, audit des comptes tous les six mois. Ajouter à cela le choix d’un hébergeur web suisse qui limite les tentatives de connexion par défaut complète le dispositif au niveau serveur.

XSS et injection SQL : les failles de sécurité qu’on ne voit pas venir

Le Cross-Site Scripting (XSS) consiste à injecter du code JavaScript malveillant dans une page web. L’attaquant cible les zones de saisie non protégées : commentaires, formulaires de contact, barres de recherche. Ce code s’exécute dans le navigateur des visiteurs suivants, volé leurs cookies de session ou les redirigeant vers des sites frauduleux. Cette faille de sécurité WordPress touche particulièrement les sites avec des formulaires non validés côté serveur. Protection : échappement systématique des données sortantes, validation stricte des entrées.

L’injection SQL vise directement la base de données. Une requête mal filtrée permet d’extraire les identifiants de connexion, de modifier le contenu ou de supprimer des tables entières. WordPress utilise des requêtes préparées via $wpdb pour son core. Le risque revient avec les plugins qui ne respectent pas cette pratique. Bref, un plugin peu réputé ouvre une porte directe sur toute la base de données.

wp-config.php : le fichier que personne ne pense à protéger

wp-config.php contient les identifiants de la base de données (hôte, nom, utilisateur, mot de passe), les clés de sécurité et des constantes critiques pour le fonctionnement de WordPress. Si ce fichier est accessible via une URL publique, un attaquant récupère en quelques secondes tout ce qu’il faut pour vider la base. La mauvaise configuration du serveur web est la cause la plus courante de cette exposition.

Sécuriser wp-config.php prend cinq minutes : ajouter un bloc dans .htaccess pour interdire tout accès HTTP direct au fichier. L’autre option est de le déplacer un niveau au-dessus de la racine publique. WordPress le détecte automatiquement. Honnêtement, c’est le type de correction qu’on retrouve absente sur 4 sites sur 10 lors d’un audit de sécurité WordPress. Non faite, non documentée, non mentionnée par l’agence qui a livré le site.

WordPress non mis à jour : la faille que tout le monde ignore

Chaque mise à jour WordPress corrige des failles documentées. Ne pas les appliquer, c’est garder une vulnérabilité connue publiquement active sur son site. Le vrai problème : ces failles de sécurité WordPress dans les anciennes versions sont répertoriées dans des bases de données accessibles à n’importe quel script d’attaque automatisé. Un site en version 6.4 avec une vulnérabilité corrigée en 6.5 est une cible indexable.

La peur de casser le site avec une mise à jour est légitime. Elle pousse beaucoup d’administrateurs à repousser indéfiniment. La solution : un environnement de staging (copie du site en ligne sur un sous-domaine privé) sur lequel tester chaque mise à jour majeure avant de l’appliquer en production. Les mises à jour mineures, elles, peuvent être activées en automatique sans risque significatif. Sécuriser WordPress correctement passe par cette discipline de maintenance, pas seulement par l’installation d’un plugin de sécurité.

Accès non sécurisé et WordPress sans HTTPS

Un site WordPress servi en HTTP (sans certificat SSL actif) transmet les données en clair entre le navigateur et le serveur. Mots de passe, informations de formulaire, cookies de session : tout est interceptable sur le même réseau Wi-Fi. Depuis 2018, Google marque les sites HTTP comme « non sécurisés » dans Chrome. Et depuis la nLPD suisse (septembre 2023), l’absence de HTTPS peut être retenue comme manquement à la protection des données.

Activer HTTPS ne suffit pas. Il faut aussi forcer la redirection 301 depuis HTTP vers HTTPS dans .htaccess, et s’assurer que tous les assets (images, scripts, feuilles de style) sont chargés en HTTPS. Un seul élément en HTTP déclenche une alerte « contenu mixte » dans le navigateur. Le résultat : le cadenas disparait, l’utilisateur voit une alerte de sécurité et quitte la page.

Sécuriser son site WordPress : la checklist qu’on applique chez VLdesign

Après 25 ans sur ce métier, j’ai construit une liste de contrôle pour sécuriser son site WordPress qui couvre 90 % des situations courantes chez les PME romandes. Elle ne remplace pas un audit complet, mais élimine les vecteurs d’attaque les plus fréquents.

• Mises à jour WordPress core activées en automatique pour les versions mineures
• Plugins actifs limités au strict nécessaire (chaque plugin inactif = surface d’attaque potentielle)
• Authentification à deux facteurs (2FA) obligatoire sur les comptes administrateurs
• Sauvegarde quotidienne vers un stockage extérieur au serveur principal
• HTTPS actif avec certificat SSL valide et redirection 301 forcée depuis HTTP
• wp-config.php protégé par règle .htaccess ou déplacé hors de la racine publique
• Plugin de sécurité actif (Solid Security ou Wordfence) avec scan hebdomadaire automatique

Sécuriser WordPress correctement demande aussi de regarder ce que le serveur fait par défaut. Un hébergement mutualisé générique n’offre pas les mêmes protections qu’une infrastructure dédiée. Versions PHP obsolètes, pare-feu inexistant, logs d’accès non monitordés : le niveau de sécurité WordPress dépend autant de l’hébergeur que du site lui-même. Le diagnostic technique de votre installation WordPress couvre ces deux niveaux et identifie les points de faiblesse spécifiques à votre configuration.

Ce qu’ont en commun tous les propriétaires piratés

Vous vous souvenez du client du lundi matin ? La chose en commun avec presque toutes les victimes que j’ai croisées : personne n’avait jamais vérifié leur installation. Pas une seule fois depuis la mise en ligne. Pas un audit de sécurité WordPress, pas un regard sur les plugins inactifs, pas un changement de mot de passe en trois ans. Le piratage n’était pas une question de malchance. C’était une question de temps.

En Suisse, la nLPD révisée (entrée en vigueur en septembre 2023) impose une obligation de notification en cas de violation de données personnelles. Si votre site WordPress collecte des formulaires de contact, des adresses e-mail ou des données client, un piratage devient un incident LPD avec obligation de déclaration au PFPDT dans les 72 heures. Ce n’est plus une question de réputation : c’est une obligation légale. Les agences qui accompagnent les PME de l’arc lémanique intègrent cette contrainte dans chaque livraison depuis 2023.

La sécurité WordPress n’est pas une préoccupation de développeur. C’est une responsabilité de propriétaire de site, au même titre que la mise à jour d’un logiciel de caisse ou la fermeture d’un local le soir. Sécuriser son site WordPress ne nécessite ni expertise technique avancée ni budget important. Les outils existent, la plupart sont gratuits, et 90 % des incidents que j’ai vus depuis 2000 étaient évitables avec les bases appliquées à temps.

Sources : W3Techs Web Technology Surveys, mai 2025 · WPScan Vulnerability Database, rapport 2024 · PFPDT, nLPD entrée en vigueur septembre 2023 · CVE-2024-12365 (W3 Total Cache 2.8.1) · CVE-2024-12240 (Page Builder SiteOrigin)