Cybersécurité : WordPress, CMS et projets maison, les failles que laissent les développeurs

« Pourquoi quelqu'un s'en prendrait-il à mon site, il n'a rien d'intéressant. » C'est l'objection qu'on entend le plus souvent, et c'est un malentendu. La quasi-totalité des piratages ne visent personne en particulier : ce sont des scripts automatisés qui balayent des millions d'adresses, testent des failles connues sur des versions obsolètes, essaient des mots de passe par défaut, et exploitent la première porte entrouverte qu'ils trouvent. Peu importe que votre site fasse 5 pages ou 5 000 : s'il tourne sur un CMS avec une extension vulnérable, ou sur un code maison écrit à la va-vite, il finira par être repéré.

Le point commun à la majorité des sites compromis n'est pas la technologie utilisée — WordPress, PrestaShop, Joomla ou développement 100% sur mesure — mais la rigueur (ou l'absence de rigueur) de celui qui l'a construit et de celui qui le maintient. Un développement pressé, sous-traité au moins cher, ou simplement jamais mis à jour, laisse des trous. C'est le message central de cet article : la sécurité n'est pas une option qu'on ajoute à la fin, c'est une conséquence directe de la qualité du travail.

WordPress & CMS : la cible n°1

WordPress alimente plus de 40% des sites web dans le monde — et c'est précisément pour cette raison qu'il concentre l'essentiel des tentatives d'intrusion automatisées. Mais il faut être précis sur la cause réelle : le cœur de WordPress lui-même est sûr. Il est maintenu par une équipe de sécurité active, les failles critiques sont corrigées en quelques jours, et les mises à jour sont automatisables. Le problème vient presque toujours d'ailleurs :

• Thèmes et plugins non mis à jour, voire abandonnés par leur éditeur — chaque extension est une porte d'entrée potentielle, et une extension qui n'est plus maintenue ne recevra jamais de correctif.
• Mots de passe faibles sur les comptes administrateurs, réutilisés d'un site à l'autre, sans authentification à deux facteurs.
• /wp-admin accessible sans aucune protection — pas de limitation des tentatives de connexion, pas de restriction d'accès, une porte grande ouverte aux attaques par force brute.
• Versions obsolètes du CMS lui-même, du PHP sous-jacent, ou de la base de données.
• Extensions douteuses installées pour gagner du temps, parfois piratées elles-mêmes (« nulled plugins »), qui embarquent une porte dérobée dès l'installation.

Le même constat vaut pour PrestaShop, Joomla ou tout autre CMS : la plateforme fournit un socle solide, mais un développeur qui installe des modules sans les vérifier, qui ne planifie aucune maintenance, ou qui livre le site sans changer les identifiants par défaut, transforme un CMS fiable en cible facile.

Les projets sur mesure ne sont pas épargnés

C'est l'idée reçue la plus dangereuse : penser qu'un développement 100% sur mesure serait automatiquement plus sûr qu'un CMS, parce qu'il est « unique » et donc moins ciblé. En réalité, un code sur mesure n'a aucun filet de sécurité communautaire — pas d'équipe de sécurité externe qui traque les failles à votre place, pas de correctif automatique. Sa sécurité dépend à 100% de la rigueur du développeur qui l'a écrit. Et un développement bâclé y laisse des failles au moins aussi graves que sur un CMS mal tenu :

• Injections SQL : des requêtes construites par concaténation de texte au lieu de requêtes préparées, qui permettent à un attaquant d'interroger — ou de modifier — directement la base de données via un simple champ de formulaire.
• Failles XSS (cross-site scripting) : des données saisies par l'utilisateur affichées sans être filtrées, ouvrant la porte à l'exécution de scripts malveillants dans le navigateur des visiteurs.
• Upload de fichiers non filtré : un formulaire qui accepte n'importe quel fichier, sans contrôle du type réel ni du contenu, permet de déposer un script malveillant directement sur le serveur.
• Absence de contrôle des droits : des pages ou des actions d'administration accessibles simplement en devinant une URL, sans vérification que l'utilisateur est bien autorisé.
• Secrets en dur dans le code : mots de passe de base de données, clés d'API, identifiants SMTP écrits en clair dans des fichiers parfois accessibles publiquement ou versionnés par erreur.
• Endpoints non protégés : des routes ou des API internes exposées sans authentification, oubliées après les tests de développement.
• Messages d'erreur bavards : des erreurs PHP affichées telles quelles, qui révèlent les chemins serveur, la structure de la base de données, ou la technologie utilisée — une carte offerte à un attaquant.

Nous le constatons régulièrement en reprenant des projets existants : ces failles ne sont pas exotiques, elles sont le résultat direct d'un développement pressé, sans revue de code, sans tests de sécurité — le genre de raccourci que prend un prestataire qui facture au plus vite plutôt qu'au plus solide.

Les conséquences d'une faille

Une vulnérabilité non corrigée n'est jamais un risque abstrait. Voici ce qui arrive concrètement quand elle est exploitée :

• Défacement : la page d'accueil remplacée par un message de piratage, visible par tous vos visiteurs.
• Spam SEO negative : des centaines de pages invisibles injectées dans votre site pour promouvoir des produits douteux, qui polluent votre référencement et peuvent faire chuter votre trafic.
• Vol de données clients : emails, mots de passe, parfois coordonnées bancaires — avec les obligations de notification RGPD qui en découlent, et le risque de sanction de la CNIL.
• Rançongiciel : le site chiffré et rendu inaccessible, avec une demande de rançon pour le débloquer.
• Blocage par Google : l'avertissement « ce site peut être piraté » ou « ce site pourrait endommager votre ordinateur » affiché dans les résultats de recherche, qui fait fuir instantanément la quasi-totalité du trafic.

Le coût d'une remédiation en urgence — nettoyage, reconstruction, gestion de crise — dépasse presque toujours, et de loin, le coût d'un audit préventif.

Comment fermer les trous

Il n'existe pas de sécurité à 100%, mais un site correctement tenu réduit la surface d'attaque de manière radicale. Les bonnes pratiques ne sont ni secrètes ni coûteuses — elles demandent simplement de la rigueur :

• Mises à jour régulières du CMS, des thèmes, des plugins, du PHP et des dépendances
• Principe du moindre privilège : chaque compte n'a accès qu'à ce dont il a réellement besoin
• Requêtes préparées systématiques pour tout accès à la base de données
• Validation et filtrage stricts de toutes les entrées utilisateur (formulaires, uploads, paramètres d'URL)
• Pare-feu applicatif (WAF) pour bloquer les tentatives d'exploitation automatisées
• Sauvegardes régulières, testées, et stockées hors du serveur principal
• HTTPS partout, avec en-têtes de sécurité renforcés (HSTS notamment)
• Authentification à deux facteurs sur tous les comptes administrateurs
• Audit de sécurité régulier pour détecter les failles avant qu'elles ne soient exploitées

Pour aller plus loin sur des sujets connexes, nous détaillons également les risques liés à l'IA et aux clés API mal protégées ou conversations indexées, ainsi que notre méthode pour un audit de sécurité serveur complet. Si votre site nécessite un suivi dans la durée plutôt qu'une intervention ponctuelle, notre offre de maintenance & infogérance couvre justement ces mises à jour et cette surveillance en continu.

FAQ