Sécurité Drupal, Joomla, Magento : les failles que personne ne vérifie
WordPress concentre toute l'attention sécurité — mais Drupal, Joomla et Magento ont leurs propres vulnérabilités critiques. Un accès non autorisé à Magento = données bancaires exposées. Les enjeux sont énormes.
- Chaque CMS a des fichiers et endpoints exposés par défaut : CHANGELOG.txt (Drupal), configuration.php.bak (Joomla), /app/etc/local.xml (Magento) — visibles sans aucun accès admin
- Les audits externes (sans accès back-office) peuvent détecter la majorité de ces failles — exactement comme le ferait un attaquant lors de sa reconnaissance initiale
- Les Batchs 1 et 2 d'Orilyt ajouteront des tests de sécurité spécifiques à chaque CMS — Joomla, Magento, PrestaShop, Drupal, OpenCart, tous en externe, tous automatiques
WordPress absorbe toute l'attention en matière de sécurité web. Les plugins vulnérables, les versions obsolètes, les brute-forces sur wp-admin — on en parle constamment. Pendant ce temps, Drupal, Joomla et Magento continuent de faire tourner des sites gouvernementaux, des portails universitaires et des boutiques e-commerce sans que personne n'audit sérieusement leur sécurité.
Les enjeux sont pourtant considérables. Une faille sur Magento, c'est potentiellement des numéros de carte bancaire exposés. Sur Drupal, c'est des données gouvernementales en danger. Sur Joomla, c'est des bases de données clients accessibles. Drupalgeddon en 2018 a affecté des centaines de milliers de sites — et des patterns similaires existent encore aujourd'hui.
Ce qui rend la situation encore plus préoccupante : la plupart de ces failles sont détectables sans aucun accès administrateur, simplement en regardant ce que le serveur expose publiquement. C'est exactement ce que fait un attaquant lors de sa phase de reconnaissance. Et c'est ce qu'Orilyt va automatiser pour votre prochain audit.
Drupal — les points faibles du géant entreprise
Drupal alimente des ministères, des universités et des entreprises du Fortune 500. Sa réputation de robustesse est méritée — mais elle crée une fausse impression de sécurité automatique. En réalité, plusieurs vecteurs d'attaque sont accessibles dès la première reconnaissance externe.
Drupal conserve un fichier CHANGELOG.txt à la racine qui révèle la version exacte installée. Un attaquant n'a besoin que de cette information pour cibler des CVE spécifiques. Ce fichier devrait être supprimé ou restreint en production.
Le script /update.php permet de mettre à jour la base de données après une mise à jour Drupal. Laissé accessible sans protection, il peut être déclenché par n'importe qui — un vecteur classique de manipulation de schéma de base de données.
Le chemin d'administration par défaut /user/login est facilement identifiable. Combiné à la détection de version via la balise meta generator (souvent présente sur les installations par défaut), cela fournit toutes les informations nécessaires pour une attaque ciblée.
Le cas Drupalgeddon (SA-CORE-2018-002) reste emblématique : une exécution de code à distance sans authentification, exploitée massivement en quelques heures. La vulnérabilité initiale était une faille d'injection SQL — mais c'est l'exposition de la version qui a permis aux attaquants de cibler les sites non patchés avec une précision chirurgicale.
Joomla — l'enfant oublié du web
Joomla occupe une position inconfortable dans l'écosystème CMS : assez populaire pour être une cible attractive, assez ignoré pour que ses failles passent inaperçues. Des millions de sites fonctionnent encore sous Joomla 3.x — une branche en fin de vie depuis décembre 2023.
Lors des mises à jour ou migrations, des fichiers de sauvegarde de la configuration principale sont parfois laissés accessibles. configuration.php.bak — ou configuration.php.old, configuration.bak.php — peut contenir les identifiants de base de données en clair.
L'interface d'administration de Joomla est accessible à /administrator/ par défaut. Aucun changement de chemin n'est proposé lors de l'installation. Ce chemin est scanné en priorité par les bots d'attaque automatiques.
Joomla expose souvent sa version exacte via la balise meta generator. Pire : laisser le mode debug activé en production (configuration.php : $debug = 1) provoque l'affichage d'informations sensibles dans les pages d'erreur — chemins serveur, requêtes SQL, variables de session.
Les extensions Joomla sont un vecteur majeur souvent sous-estimé. Contrairement à WordPress qui a un dépôt centralisé avec des systèmes de signalement, l'écosystème Joomla compte des milliers d'extensions tierces dont beaucoup ne sont plus maintenues. Des CVE connus existent pour des extensions encore très déployées.
Magento — là où l'argent rencontre le risque
Magento (Adobe Commerce) est le CMS e-commerce de référence pour les boutiques à fort volume. C'est aussi l'une des cibles les plus lucratives pour les attaquants. Les attaques Magecart — injection de code JavaScript malveillant dans le checkout pour capturer les données de carte — ont affecté des milliers de boutiques Magento.
Magento 1.x exposait un downloader à /downloader/ permettant d'installer des extensions. Magento 2.x a son wizard d'installation à /setup/. Ces endpoints, laissés accessibles après installation, sont des portes d'entrée directes pour les attaquants.
Le fichier /app/etc/local.xml (Magento 1) ou /app/etc/env.php (Magento 2) contient les identifiants de base de données, les clés de chiffrement et d'autres secrets. Un serveur mal configuré qui sert ce fichier directement expose l'intégralité des données de la boutique.
Magento propose de personnaliser le chemin admin lors de l'installation, mais beaucoup de déploiements conservent /admin/ ou /index.php/admin/. La gestion des patches de sécurité est également un problème : les marchands retardent souvent les mises à jour par peur de casser des personnalisations, laissant des CVE critiques non corrigés pendant des mois.
Les attaques Magecart illustrent parfaitement la réalité du risque : un attaquant n'a pas besoin d'accès administrateur pour causer des dégâts catastrophiques. Une simple injection JavaScript dans le formulaire de checkout — rendue possible par une version non patchée ou une extension vulnérable — suffit à exfiltrer toutes les données de paiement.
PrestaShop et OpenCart — les outsiders e-commerce
PrestaShop et OpenCart ne bénéficient pas de la même visibilité médiatique que Magento, mais ils alimentent des centaines de milliers de boutiques en ligne. Leurs vulnérabilités sont d'autant plus dangereuses qu'elles sont rarement auditées.
PrestaShop renomme normalement le dossier admin lors de l'installation, mais /admin-dev/ est parfois laissé en place dans les environnements de développement déployés en production. Les fichiers /app/config/parameters.php et /config/settings.inc.php contiennent les identifiants de base de données.
OpenCart conserve /admin/ comme chemin par défaut dans la majorité des installations. Plus critique : les fichiers config.php et admin/config.php contiennent le chemin absolu du serveur, les identifiants de base de données et les clés secrètes — et sont parfois lisibles directement depuis le navigateur sur des serveurs mal configurés.
Un pattern d'injection SQL connu affecte plusieurs versions d'OpenCart, notamment dans les modules de filtrage de produits. Ces vulnérabilités sont documentées et des PoC publics existent — rendant l'exploitation triviale pour n'importe quel script kiddie ayant accès à un moteur de recherche.
Pourquoi les audits externes détectent ce que les outils internes ratent
La grande majorité des outils de sécurité CMS exigent un accès administrateur ou l'installation d'un plugin de monitoring. Cette approche a un angle mort fondamental : elle présuppose que l'attaquant ne peut pas voir ce que l'outil ne regarde pas.
Un audit externe teste ce qu'un attaquant voit depuis l'extérieur. Aucune installation, aucun accès, aucune dépendance. Le serveur répond ou ne répond pas — et cette réponse révèle tout.
Les mêmes requêtes HTTP qu'un scanner de sécurité offensif : chercher CHANGELOG.txt, tester /administrator/, demander /app/etc/env.php. Si un attaquant peut le faire, l'outil doit le faire.
La version du CMS est souvent exposée dans les meta tags, les headers HTTP, les fichiers README ou les assets versionnés. Connaître la version sans accès admin est la première étape de n'importe quelle attaque ciblée.
L'audit externe ne remplace pas un pentest approfondi — mais il détecte les low-hanging fruits que les attaquants cherchent en priorité. Dans 80 % des intrusions réelles, le point d'entrée était une information accessible publiquement que personne n'avait pensé à vérifier.
La feuille de route sécurité multi-CMS d'Orilyt
Orilyt audite aujourd'hui principalement les sites WordPress. La prochaine étape — déjà en développement — est d'étendre ces capacités aux CMS les plus utilisés sur le web. L'approche reste la même : tout en externe, tout automatique, tout actionnable.
Joomla (configuration.php.bak, /administrator/ non protégé, version meta generator), Magento (/downloader/, /setup/, /app/etc/local.xml), PrestaShop (/admin-dev/, parameters.php). Ces tests vérifient l'exposition des fichiers et endpoints les plus dangereux.
Drupal (CHANGELOG.txt, update.php, détection de version), OpenCart (config.php exposé, /admin/ sans protection supplémentaire), Ghost (version dans les assets, endpoints d'API exposés). Tests combinant détection CMS + vérification de fichiers sensibles + analyse des headers.
Tous ces tests seront disponibles dans le même rapport Orilyt que vous connaissez déjà — avec les recommandations FIA (Fait, Impact, Action) prêtes à présenter à vos clients. Aucune configuration supplémentaire, aucun accès requis.
L'angle mort que vous pouvez combler dès aujourd'hui
La sécurité des CMS non-WordPress est un angle mort massif dans l'industrie du web. Les propriétaires de sites Joomla, Magento ou Drupal ont souvent une fausse impression de sécurité parce que leur CMS est "moins ciblé" que WordPress. C'est un raisonnement dangereux : les attaquants s'adaptent à la cible, pas l'inverse.
Pour les freelances et les agences, cet angle mort est une opportunité. Proposer un audit de sécurité à un client sous Magento qui n'a jamais vérifié si /app/etc/env.php est accessible — c'est apporter une valeur immédiate, démontrable et tangible. C'est aussi potentiellement lui éviter une catastrophe.
Orilyt va rendre ces vérifications automatiques. En attendant les Batchs 1 et 2, les tests WordPress existants couvrent déjà les patterns communs à tous les CMS : en-têtes de sécurité, SSL, redirections, réputation IP. Un audit complet reste un excellent point de départ.