Un client m'appelle un mardi matin, paniqué. Son site Joomla affiche une page blanche, et son hébergeur lui a coupé l'accès SMTP parce qu'il envoyait 40 000 mails par heure. Douze ans de contenu, 300 articles, une base clients. Tout ça parce qu'une extension de formulaire laissée à l'abandon depuis deux ans. J'ai mis quatre jours à le remettre en ligne. Voilà ce que j'ai appris — et ce que je fais aujourd'hui pour que ça ne vous arrive pas.
Points clés à retenir
- Joomla 3 n'est plus maintenu depuis août 2023 : si vous y êtes encore, c'est votre premier chantier, pas votre dernier.
- Une extension tierce non mise à jour est la porte d'entrée dans la majorité des piratages que j'ai traités.
- La défense en profondeur (droits fichiers, .htaccess, 2FA, WAF) compte plus que n'importe quel plugin « tout-en-un ».
- Un plan de réponse à incident écrit à l'avance vaut mieux que trois extensions de sécurité empilées sans stratégie.
- Les sauvegardes hors site, testées, sont la seule chose qui vous sauve vraiment après une compromission.
Pourquoi votre site Joomla est une cible, même si vous êtes « trop petit pour intéresser qui que ce soit »
J'entends cette phrase à chaque audit. « Personne ne va s'attaquer à mon site de 20 pages. » C'est faux, et la raison est presque décevante de banalité : personne ne s'attaque à votre site. Des robots scannent l'intégralité de l'espace IPv4 en continu, à la recherche de signatures connues. Un Joomla en version 3.9, un composant avec un numéro de révision qui traîne dans le code source, un /administrator accessible sans restriction : ça suffit à déclencher une tentative automatisée.
Vous n'êtes pas visé. Vous êtes scanné. Nuance.
Le vrai problème de Joomla sur ce terrain, c'est son écosystème. Le CMS en lui-même tient bien la route — l'équipe de sécurité réagit vite sur les failles du core. Mais un site Joomla typique, c'est 15 à 30 extensions tierces développées par des équipes de deux personnes, parfois abandonnées au bout de six mois. Chacune est une surface d'attaque indépendante. Dans mon expérience, 8 compromissions sur 10 que j'ai traitées venaient d'une extension ou d'un template, jamais du cœur de Joomla.
Quelles versions sont encore supportées, et pourquoi ça change tout
La fin de support de Joomla 3 est actée depuis août 2023. Ça signifie : plus aucun correctif de sécurité, même sur une faille critique. Si votre site tourne encore dessus, vous n'êtes pas « en retard », vous êtes sur un système qui ne recevra plus jamais de rustine.
Joomla 4 est en fin de vie proche, ce qui laisse Joomla 5 comme seule branche sérieusement maintenue. Migration obligatoire, donc, mais avec une nuance : une migration forcée dans l'urgence, un vendredi soir, sur un site mal sauvegardé, casse plus de choses qu'elle n'en répare. Prévoyez-la, ne la subissez pas.
| Version | Support sécurité | Ce que je recommande |
|---|---|---|
| Joomla 3 | Terminé | Migrer en priorité absolue, sur environnement de test |
| Joomla 4 | Fin de cycle | Planifier la montée vers Joomla 5 sous quelques mois |
| Joomla 5 | Actif | Rester à jour, surveiller les extensions à chaque release |
Sécuriser un site Joomla concrètement : ce qu'on configure vraiment
Les listes d'extensions à installer, vous les trouverez partout. Ce qui manque, c'est le comment. Le durcissement d'un Joomla tient à une poignée de réglages qu'on peut faire en une heure, et que 9 sites sur 10 que j'audite n'ont jamais touchés.
Droits fichiers et .htaccess : les fondations
Le principe est simple : un serveur web n'a jamais besoin d'écrire dans un fichier PHP. Si une extension arrive à modifier un fichier de code, c'est déjà perdu. En pratique :
- Les dossiers en 755, les fichiers en 644, sauf
configuration.phpqu'on peut passer en 444 après installation. - Interdire l'exécution PHP dans les dossiers
/images,/tmpet/cachevia un.htaccessdédié. C'est la parade la plus efficace contre les webshells qui s'y planquent, et personne ne le fait. - Bloquer l'accès direct à
configuration.phpet aux fichiers.log. - Désactiver le listing des répertoires.
- Un second compte administrateur, avec un mot de passe long, en secours. Un seul compte admin actif : c'est le minimum.
Double authentification et WAF : la couche qui stoppe 90 % des tentatives automatisées
La 2FA sur le back-office Joomla est intégrée depuis la version 4. Activez-la. Ce n'est pas une suggestion polie : c'est la mesure avec le meilleur rapport effort/protection de toute cette liste. Un mot de passe volé ne suffit plus à entrer.
Pour le WAF, deux écoles. Un WAF applicatif côté serveur (type ModSecurity chez l'hébergeur) ou un service externe posé devant le site. J'ai longtemps été sceptique sur les WAF — trop de faux positifs, trop de tickets clients cassés par une règle trop zélée. Et puis j'ai vu le nombre de requêtes malveillantes bloquées sur un site de 15 pages. J'ai changé d'avis. Franchement, un site vitrine reçoit des centaines de tentatives par semaine.
Le compromis que j'applique maintenant : WAF en mode « détection » pendant deux semaines, on regarde les logs, puis on passe en mode blocage. Ça évite de casser le formulaire de contact du commercial un jour de salon.
Extensions et mises à jour : le suivi qui évite 80 % des ennuis
Un site Joomla se met à jour tout seul, ou presque. Le piège, ce sont les extensions. Un template payant abandonné par son développeur, un plugin de galerie dont la dernière version date de trois ans : vous ne le voyez pas, il fonctionne, personne ne s'en plaint. Jusqu'au jour où.
Ce que je fais, concrètement, pour un client :
- Lister toutes les extensions installées, en repérant celles qui n'ont pas eu de release depuis un an.
- Désinstaller tout ce qui n'est plus utilisé. C'est bête, mais un composant dormant reste une porte ouverte.
- Configurer les notifications de mise à jour Joomla et surveiller les avis de sécurité publiés par l'équipe sécurité du projet.
- Mettre à jour d'abord sur un clone du site, jamais en direct.
Un détail qui tue : les extensions désactivées restent vulnérables. « Désactivé » ne veut pas dire « inactif » côté code. Si le fichier est là, l'attaque peut l'atteindre.
Que faire après un piratage de votre site Joomla
La question qu'on me pose le plus, et à laquelle aucun guide ne répond vraiment. Voici l'ordre dans lequel j'interviens. Il n'est pas négociable.
Étape 1 : isoler, pas réparer. Le réflexe est de vouloir nettoyer tout de suite. Erreur. Basculez le site en maintenance, coupez les accès FTP et SSH, mais laissez-le accessible côté fichier pour l'analyse. Si vous coupez tout, vous perdez les preuves.
Étape 2 : identifier la porte d'entrée. Logs serveur, logs Joomla, dates de modification des fichiers. Un fichier PHP modifié à 3h du matin dans /components/com_quelquechose/, c'est un indice. Un compte admin créé à une date suspecte, un autre. Sans identifier la faille, la restauration ne sert qu'à se faire repirater dans les 48 heures.
J'ai fait cette erreur une fois — restauré une sauvegarde sans chercher l'origine. Le site était de nouveau compromis au bout de trois jours. Je ne recommence plus.
Étape 3 : nettoyer ou restaurer. Sur un site simple, une restauration propre depuis une sauvegarde antérieure à la compromission est souvent la bonne voie. Sur un site à contenu dynamique, il faut nettoyer, ce qui demande de comparer les fichiers avec une version saine du core et des extensions.
Étape 4 : changer tout. Mots de passe admin, FTP, SSH, base de données, accès hébergeur. Tout. Y compris les clés d'API stockées dans le site, qui sont peut-être parties avec les données.
Étape 5 : refermer la faille, puis surveiller. Reprendre l'étape 2 et patcher précisément ce qui a permis l'intrusion. Ensuite, surveiller les logs pendant plusieurs semaines.
Le volet que personne ne veut entendre
Aucune extension ne rend un site inviolable. J'ai vu des sites équipés de trois plugins de sécurité se faire compromettre parce que personne n'avait regardé un dossier dans /images depuis deux ans. Inversement, un site sans plugin dédié, mais avec des droits fichiers corrects, la 2FA active et des sauvegardes hors site testées, tient beaucoup mieux qu'on ne le croit.
La sécurité d'un site Joomla, c'est rarement un problème d'outil. C'est un problème de routine. Trente minutes par mois, une checklist écrite, un plan de restauration connu. Ce que je vois chez mes clients qui n'ont jamais été piratés, ce n'est pas un arsenal technique. C'est une personne qui met à jour, note ce qu'elle fait, et sait où sont ses sauvegardes.
Alors la vraie question n'est pas « quelle extension installer ». C'est : si demain matin votre site affiche une page blanche, savez-vous quoi faire dans les 30 prochaines minutes ? Si la réponse est non, vous avez votre priorité de la semaine.
