Joomla sécurité - Étapes pour sécuriser votre site contre les pirates

Durcir la sécurité d’un site Joomla consiste à réduire les possibilités d’intrusion, à limiter les dégâts si un contrôle échoue et à rendre l’incident détectable. Ce travail ne repose donc ni sur une extension miracle ni sur le simple fait de masquer l’adresse du back-office.

Ce guide propose un plan d’action technique : inventaire du socle, correction des vulnérabilités, protection des comptes, sécurisation des formulaires et du serveur, sauvegardes restaurables, journalisation et réponse à incident. Il complète notre guide général sur les bonnes pratiques de sécurité Joomla, sans reprendre le même angle éditorial.

Si personne n’est clairement responsable de ces contrôles dans votre organisation, notre maintenance de sites Joomla permet de structurer les mises à niveau, les sauvegardes, la supervision et les interventions techniques.

Laurent Lacoste – Architecte web et expert Joomla depuis 2009.

1. Comprendre la surface d’attaque d’un site Joomla

Un site Joomla n’est pas attaqué uniquement parce qu’un pirate le vise personnellement. Des robots parcourent le Web, identifient les technologies exposées et testent automatiquement des vulnérabilités connues, des identifiants compromis, des formulaires insuffisamment filtrés ou des fichiers oubliés.

La surface d’attaque comprend notamment :

• le cœur Joomla, ses API et son interface d’administration ;
• les composants, modules, plugins et templates, actifs ou non ;
• les comptes, sessions, mots de passe, clés API et procédures de récupération ;
• les formulaires, pièces jointes, téléversements et éditeurs de contenu ;
• PHP, la base de données, le serveur web, le panneau d’hébergement et le DNS ;
• les sauvegardes, dépôts de code, espaces de préproduction et outils de déploiement ;
• les services tiers : SMTP, analytics, paiement, CRM, CDN, WAF et stockage.

Le principe utile est celui de la défense en profondeur : plusieurs contrôles indépendants réduisent la probabilité qu’une seule erreur permette une compromission complète. Le WAF peut filtrer une requête hostile, mais les correctifs restent nécessaires ; l’authentification multifacteur protège un compte, mais les droits doivent encore être limités.

Note de lecture : cette infographie reprend des répartitions issues de publications antérieures. Elle illustre des familles de risques, mais ses pourcentages ne doivent pas être interprétés comme une statistique universelle ou comme une photographie du parc Joomla en 2026.

2. Partir d’une version Joomla maintenue

Au moment de la publication, Joomla 6.1.2 et Joomla 5.4.7 sont les versions correctives annoncées par le projet. Leur publication du 7 juillet 2026 comprend plusieurs correctifs de sécurité. Joomla 5.4 bénéficie encore de correctifs de sécurité jusqu’en octobre 2027, ce qui laisse le temps de préparer une évolution vers Joomla 6 lorsque les extensions ou le template ne sont pas encore compatibles.

Le numéro de version ne suffit pas : il faut consulter les notes de version et les problèmes connus. Joomla 5.4.7 et 6.1.2 ont notamment fait l’objet d’un correctif temporaire pour un problème affectant certains paramètres d’articles. Une procédure de maintenance sérieuse combine donc :

1. lecture des annonces de sécurité et des notes de version ;
2. sauvegarde complète et test de restauration ;
3. copie de préproduction représentative ;
4. contrôle de compatibilité du template et des extensions ;
5. mise à niveau et recette fonctionnelle ;
6. surveillance renforcée après la mise en production.

Le projet Joomla recommande lui-même de tester l’évolution vers Joomla 6 sur une copie du site de production. Le plugin de rétrocompatibilité peut faciliter la transition de certaines extensions, mais il ne doit pas être confondu avec une preuve de compatibilité durable.

3. Auditer le cœur, les extensions et le template

3.1. Construire l’inventaire technique

Créez une liste des composants, modules, plugins, packages et templates avec leur version, leur éditeur, leur rôle, leur statut et leur dernière utilisation. Ajoutez les overrides, scripts personnalisés, tâches planifiées, hooks de paiement, formulaires et connecteurs externes.

Pour chaque élément, prenez une décision explicite :

• conserver : fonction utile, maintenue et compatible ;
• mettre à niveau : fonction utile, mais version obsolète ;
• remplacer : besoin toujours présent, extension non maintenue ;
• supprimer : doublon, fonction abandonnée ou test jamais retiré.

3.2. Contrôler les extensions vulnérables ou abandonnées

Consultez la liste des extensions vulnérables, les éléments classés dans la VEL résolue et le portail Joomla Vulnerable Extensions List. Comparez le nom et la version exacte : le fait qu’une extension ait connu une vulnérabilité ne signifie pas nécessairement que sa version corrigée reste dangereuse.

Vérifiez également le site de l’éditeur, le journal des changements, les annonces de sécurité et la compatibilité déclarée dans le Joomla Extensions Directory. Une extension non activée reste du code présent sur le serveur ; si elle n’est plus utile, désinstallez-la proprement et vérifiez les fichiers, tables et tâches qu’elle laisse derrière elle.

3.3. Mettre à niveau sans intervenir directement en production

Le système de mise à jour Joomla facilite la détection des versions disponibles. Il ne remplace pas la recette. Avant une intervention :

1. figez l’inventaire et les versions installées ;
2. sauvegardez fichiers, base de données et configuration serveur ;
3. appliquez les changements sur une préproduction protégée ;
4. testez l’administration, les formulaires, les e-mails, les comptes et les parcours métier ;
5. comparez les logs et les performances ;
6. préparez un retour arrière documenté.

4. Durcir les comptes et l’administration Joomla

4.1. Utiliser des comptes nominatifs

Chaque administrateur doit disposer de son propre compte. Les comptes partagés empêchent d’attribuer une action à une personne, compliquent le départ d’un collaborateur et favorisent la diffusion incontrôlée du mot de passe.

Supprimez ou désactivez les comptes inutiles, contrôlez les adresses de récupération et évitez les identifiants trop prévisibles. Le changement d’un nom d’utilisateur peut réduire certaines tentatives opportunistes, mais il ne remplace pas un mot de passe unique, l’authentification multifacteur et la limitation des droits.

4.2. Appliquer le principe du moindre privilège

Attribuez uniquement les permissions nécessaires à la mission réelle. Un rédacteur n’a pas besoin d’installer des extensions ; un prestataire ponctuel n’a pas à conserver un accès Super Utilisateur après son intervention. Contrôlez les groupes, niveaux d’accès et autorisations des composants sensibles.

Prévoyez une revue périodique des comptes et une procédure de retrait des accès qui couvre aussi l’hébergement, le DNS, le CDN, le gestionnaire de mots de passe, les dépôts et les services externes.

4.3. Renforcer les mots de passe et la récupération

Imposez des mots de passe longs, uniques et stockés dans un gestionnaire. La complexité visuelle ne compense pas la réutilisation d’un mot de passe compromis. Sécurisez également la boîte e-mail utilisée pour la récupération, car elle peut permettre de reprendre le contrôle du compte Joomla.

4.4. Activer l’authentification multifacteur

Joomla intègre un système d’authentification multifacteur. Activez-le au minimum pour les comptes privilégiés et conservez les codes de secours dans un emplacement protégé. Le guide Joomla présente notamment les méthodes TOTP et leurs paramètres.

Si vous utilisez Google Authenticator, les applications sont disponibles pour iPhone et Android. La page historique du JED consacrée à l’authentification à deux facteurs reste conservée comme ressource, mais les fonctions natives actuelles doivent être évaluées avant d’ajouter une extension.

4.5. Réduire l’exposition du back-office

Lorsque le contexte le permet, limitez l’accès à l’administration par VPN, liste d’adresses IP, authentification supplémentaire au niveau du serveur ou règles de WAF. Cette approche est plus robuste que le simple changement de l’URL /administrator.

Un chemin personnalisé peut réduire le bruit dans les journaux, mais il relève de l’obscurcissement : il ne corrige ni une extension vulnérable ni un compte compromis. Ajoutez une limitation des tentatives, des alertes de connexion et une durée de session adaptée aux usages.

5. Sécuriser les formulaires, CAPTCHA et téléversements

Les formulaires exposent des champs, des traitements d’e-mail et parfois des téléversements de fichiers. Vérifiez le filtrage côté serveur, les jetons anti-CSRF, les droits, les limites de taille, les extensions autorisées, le type MIME et le stockage.

Pour les fichiers envoyés par les utilisateurs, l’OWASP recommande notamment une liste d’extensions autorisées, un renommage contrôlé, une limite de taille et, lorsque c’est possible, un stockage hors de la racine web. Un contrôle antivirus ou une analyse spécialisée peut compléter le dispositif selon la sensibilité du service.

Un CAPTCHA peut réduire certains abus automatisés, mais il ne protège pas une faille de téléversement et ne remplace pas la limitation de débit. Choisissez une solution maintenue, accessible, compatible avec votre politique de confidentialité et proportionnée au risque.

6. Durcir le serveur, les fichiers et le pare-feu applicatif

6.1. Maintenir l’environnement d’exécution

Le serveur doit utiliser des versions supportées de PHP, de la base de données, du serveur web et des bibliothèques système. Pour Joomla 6, la documentation technique indique PHP 8.3 au minimum et recommande PHP 8.4 ; contrôlez toutefois les prérequis exacts de votre version et de vos extensions avant toute modification.

Désactivez les services inutiles, séparez les environnements, protégez les interfaces d’administration de l’hébergeur et limitez les accès à la base. Les secrets ne doivent pas être présents dans un dépôt public, un ticket ou un fichier de sauvegarde accessible depuis le Web.

6.2. Utiliser SFTP ou SSH et contrôler les permissions

Évitez le FTP non chiffré. Utilisez SFTP ou SSH avec des comptes nominatifs et, si possible, des clés. Les permissions doivent être adaptées à la configuration du serveur : les valeurs couramment utilisées de 644 pour les fichiers et 755 pour les répertoires sont des repères, pas une règle à appliquer aveuglément à tous les hébergements. Les permissions 777 ne constituent pas une solution acceptable.

Identifiez précisément les répertoires qui doivent rester inscriptibles. Une extension ne devrait pas pouvoir modifier l’ensemble du site si sa fonction ne l’exige pas.

6.3. Ajouter un WAF sans lui déléguer toute la sécurité

Un pare-feu applicatif analyse le trafic HTTP et peut filtrer des motifs d’attaque, limiter des requêtes ou protéger l’administration. Il ajoute une couche utile contre les attaques automatisées, mais ses règles peuvent produire des faux positifs et ne corrigent pas le code vulnérable.

Documentez les règles, les exceptions, les journaux et le responsable de leur maintenance. Si vous utilisez Sucuri, le tableau de bord Sucuri et le service de pare-feu Sucuri figurent parmi les ressources historiques de l’article. Vérifiez les offres, les conditions et l’architecture actuelles avant toute décision.

7. Sauvegarder, journaliser et superviser Joomla

7.1. Construire une stratégie de sauvegarde restaurable

Une sauvegarde doit couvrir les fichiers, la base de données, les médias, la configuration et les informations nécessaires au redémarrage. Appliquez au minimum quatre exigences :

• automatique : le processus ne dépend pas d’un rappel manuel ;
• hors site : une copie n’est pas stockée uniquement sur le serveur protégé ;
• redondante : plusieurs versions sont conservées selon une rétention définie ;
• testée : une restauration complète est réalisée et chronométrée.

Des outils comme Akeeba Backup peuvent automatiser une partie du processus. Vérifiez la destination réelle des archives, le chiffrement, la rotation, les alertes d’échec et l’accès aux clés nécessaires à la restauration.

7.2. Conserver des journaux exploitables

Activez les journaux utiles de Joomla, du serveur web, de PHP, du WAF, de l’hébergeur et des services critiques. Synchronisez l’heure des systèmes et définissez une durée de conservation cohérente avec le risque et les obligations applicables.

Surveillez notamment :

• les connexions réussies et échouées à l’administration ;
• les créations de comptes et modifications de droits ;
• les installations, suppressions et mises à niveau d’extensions ;
• les modifications de configuration et de template ;
• les erreurs répétées, réponses 401, 403, 404 et 5xx inhabituelles ;
• les nouveaux fichiers exécutables et changements d’intégrité ;
• les pics d’envoi d’e-mails, de charge ou de trafic sortant.

Le composant Joomla User Actions Log peut contribuer à tracer certaines actions. Pour une investigation sérieuse, les journaux doivent être exportés ou protégés afin qu’un attaquant ne puisse pas les effacer avec le site compromis.

7.3. Définir des alertes actionnables

Une alerte sans responsable ni procédure finit par être ignorée. Pour chaque signal, documentez le seuil, le destinataire, le délai de réaction, les vérifications et le niveau d’escalade. Testez les alertes comme vous testez les sauvegardes.

8. Préparer la réponse à incident avant le piratage

Si une compromission est suspectée, l’objectif n’est pas seulement de remettre la page d’accueil en ligne. Il faut contenir l’incident, préserver les éléments utiles à l’analyse, identifier la porte d’entrée, supprimer la persistance et restaurer un environnement de confiance.

1. Isoler : limiter l’exposition ou placer le site en maintenance sans détruire immédiatement les traces.
2. Préserver : copier les fichiers, la base, les logs, les tâches et les configurations avant nettoyage.
3. Qualifier : identifier la période, les comptes, fichiers, extensions et données concernés.
4. Révoquer : changer les mots de passe, clés, jetons, accès SSH, base, SMTP, CDN et services tiers.
5. Éradiquer : repartir de paquets fiables, corriger la vulnérabilité et retirer les portes dérobées.
6. Restaurer : remettre en service depuis une base saine et surveiller les indicateurs de récidive.
7. Notifier : évaluer les obligations contractuelles, réglementaires et relatives aux données personnelles.
8. Capitaliser : documenter la cause, les impacts et les contrôles à améliorer.

Évitez de restaurer automatiquement une archive sans connaître sa date de compromission. Une sauvegarde peut contenir la même porte dérobée que le site en production.

9. Checklist de validation du durcissement Joomla

10. FAQ sur le durcissement et la sécurité Joomla

Joomla est-il sécurisé en 2026 ?

Joomla fournit un socle activement maintenu, avec des mécanismes de droits, de mise à niveau et d’authentification multifacteur. La sécurité du site dépend toutefois des extensions, du template, du serveur, des accès et de la continuité de la maintenance.

Faut-il passer immédiatement de Joomla 5.4 à Joomla 6 ?

Pas sans vérification. Joomla 5.4 reçoit encore des correctifs de sécurité jusqu’en octobre 2027. Joomla 6 doit être privilégié pour un nouveau projet et planifié pour l’existant après contrôle des extensions, du template, de PHP et des développements spécifiques.

Changer l’URL d’administration suffit-il contre le brute force ?

Non. Cela peut réduire le bruit automatisé, mais ne protège pas un compte compromis ou une extension vulnérable. Privilégiez la MFA, des comptes nominatifs, une limitation des tentatives, des alertes et, si possible, une restriction par VPN, IP ou WAF.

Un CAPTCHA protège-t-il les formulaires Joomla ?

Il peut limiter certains robots, mais ne corrige pas les défauts de validation, d’autorisation ou de téléversement. Associez-le à un filtrage côté serveur, une limitation de débit, des jetons anti-CSRF et des contrôles sur les fichiers.

Faut-il installer une extension de sécurité Joomla ?

Seulement si elle couvre un besoin identifié et reste maintenue. Une extension peut faciliter le blocage, l’intégrité ou les alertes, mais elle ajoute aussi du code et une dépendance. Évaluez d’abord les fonctions natives, le serveur et le WAF.

À quelle fréquence faut-il contrôler les mises à niveau ?

Les alertes de sécurité doivent être suivies dès leur publication. En complément, réalisez au moins un contrôle mensuel du cœur et des extensions, avec une surveillance plus rapprochée pour un site e-commerce ou exposant des données sensibles.

Que faire si un site Joomla est déjà piraté ?

Isolez-le, préservez les preuves, révoquez les accès et recherchez la cause avant de restaurer. Ne vous contentez pas de supprimer le fichier visible : une porte dérobée, un compte ou une tâche planifiée peut permettre le retour de l’attaquant.

Comment savoir si une sauvegarde Joomla est fiable ?

Restaurez-la sur un environnement isolé, vérifiez les fichiers, la base, les médias et les parcours importants, puis mesurez le délai complet. Un e-mail indiquant que la sauvegarde a réussi ne prouve pas qu’elle est exploitable.

Conclusion : le durcissement Joomla doit produire des preuves

Un site réellement sécurisé n’est pas simplement « à jour ». Il dispose d’un inventaire, de comptes maîtrisés, de protections complémentaires, de sauvegardes restaurées, de journaux exploitables et d’une procédure d’incident connue.

Le bon niveau de sécurité dépend du risque : un site institutionnel, un extranet et une boutique e-commerce ne nécessitent pas les mêmes contrôles. Dans tous les cas, chaque mesure doit avoir un responsable, une fréquence et une preuve de fonctionnement.