---
title: "Sécuriser son site Joomla en 2026 : Le guide d'une fortification en couches"
date: 2026-08-02
author: "Eddy"
categories:
  - name: "Tutoriel Joomla"
    url: "https://eddy-vh.com/tutoriel-joomla.md"
---

# Sécuriser son site Joomla en 2026 : Le guide d'une fortification en couches

Ces derniers mois, l'écosystème des CMS — et Joomla ne fait pas exception — subit une vague d'attaques automatisées particulièrement intenses. La plupart du temps, les pirates ne ciblent pas le cœur du système, mais profitent de failles dans des extensions tierces ou d'un manque de réactivité dans l'application des mises à jour.

 Pour protéger efficacement un site web, la sécurité ne doit pas reposer sur un seul outil, mais sur un **principe de défense en profondeur** : multiplier les barrières pour qu'un attaquant franchissant la première couche se heurte immédiatement à la suivante.

 Cet article est issu de ma propre expérience. Mes sites sont protégés selon cet article et je n'ai subi aucune attaque ni piratage de quelque sorte que ce soit.

 
## Gestionnaires de mots de passe & Passkeys (Clés d'accès)

 Au-delà des configurations techniques du serveur, **la gestion des identifiants reste le pilier central de votre sécurité**. Réutiliser le même mot de passe sur plusieurs services ou opter pour des combinaisons simples ouvre directement la porte aux attaques par credential stuffing (test automatisé de fuites de données).

 
- **Générez des mots de passe uniques et complexes :**

 Utilisez un gestionnaire de mots de passe (tel que *Bitwarden*, *1Password*, *KeePass*...) pour créer et stocker des mots de passe forts de 20+ caractères pour votre compte d'hébergement, votre accès SSH/DB et vos comptes administrateurs Joomla.
- **Passez aux Passkeys (Clés d'accès) :**

 De plus en plus de solutions (dont *Bitwarden*, *1Password*, Apple ou Google) prennent désormais en charge les **Passkeys**. Basées sur la norme FIDO2 / WebAuthn, ces clés d'accès cryptographiques remplacent avantageusement les mots de passe traditionnels : elles sont **insensibles au hameçonnage (phishing)** et simplifient la connexion via la biométrie de votre appareil ou votre coffre-fort numérique.

 
## 1. Verrouiller les accès : L'hébergement et l'Administration

 La première ligne de défense consiste à fermer la porte à clé et à vérifier l'identité de quiconque tente d'entrer.

 
### A. L'accès à l'hébergement

 
- **Obligation de la 2FA / Passkeys :** Active la double authentification (TOTP) ou, mieux encore, l'utilisation de clés d'accès (Passkeys / FIDO2) sur le panneau de ton hébergeur (cPanel, Plesk, etc.).
- **Repenser le FTP :** Si tu le peux, **supprime totalement les comptes FTP**. Passer directement par le gestionnaire de fichiers sécurisé de ton hébergeur élimine le risque d'interception de mots de passe en clair. Si le FTP est indispensable, exige le protocole **SFTP** avec authentification par clé SSH.

 
### B. L'administration Joomla (`/administrator`)

 
- **Double protection par `.htpasswd` (uniquement sur serveur Apache) :** En plus des identifiants de Joomla, protège le dossier `/administrator` par une authentification HTTP Basic à l'aide d'un fichier `.htaccess` et `.htpasswd`. Cela bloque les robots d'attaque par force brute avant même qu'ils n'atteignent le formulaire de connexion de Joomla.
- **Double authentification dans Joomla :** Active la 2FA (TOTP / WebAuthn) pour tous les comptes Super Administrateurs.

 Certains hébergeur offrent la gestion de protection par **htpasswd** depuis leur Panel. Sinon, des extensions telle qu'[**Admin Tools d'Akeeba**](https://www.akeeba.com/products/admin-tools.html) permettent également la mise en place de ce type de protection.

 
## 2. La réactivité absolue : Automatiser les mises à jour

 Une extension vulnérable non mise à jour est la porte d'entrée nr. 1 des attaques RCE (exécution de code à distance). Le problème n'est pas tant de savoir *comment* mettre à jour, mais *à quelle vitesse*.

 Même pour un seul site, un webmaster peut être indisponible (vacances, maladie, surcharge) au moment précis où une faille critique est divulguée.

 
- **Utiliser un outil de centralisation / automatisation :** Des solutions comme [**Panopticon**](https://www.akeeba.com/products/panopticon.html) permettent de programmer et d'automatiser l'application des correctifs dès leur parution.
- **Désinstaller l'inutile :** Supprime (et ne te contente pas de désactiver) toutes les extensions, modules ou templates non utilisés.

 
## 3. Sécuriser le dossier `/images` : Bloquer l'exécution de scripts

 Le dossier `/images` est la cible privilégiée des téléversements malveillants. Si un pirate réussit à y envoyer un fichier PHP malveillant (webshell), il cherchera à l'exécuter.

 
### La solution : Neutraliser le dossier via `.htaccess`

 En plaçant un fichier `.htaccess` directement dans le dossier `/images/`, tu interdis formellement au serveur d'exécuter du code exécutable, tout en laissant passer les images légitimes.

 ```markup

  # 1. Désactiver le moteur PHP dans ce dossier
<IfModule mod_php7.c>
    php_flag engine off
</IfModule>
<IfModule mod_php.c>
    php_flag engine off
</IfModule>

# 2. Bloquer l'accès direct aux fichiers exécutables
<FilesMatch "\.(php|php[0-9]|phtml|phar|cgi|pl|exe|sh|py|jsp|asp|htm|html)$">
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order allow,deny
        Deny from all
    </IfModule>
</FilesMatch>

# 3. Interdire le listing du répertoire
Options -Indexes

```

 **Comment tester son efficacité ?**

 Crée temporairement un fichier nommé `test.php` contenant `<?php echo "test"; ?>` dans le dossier `/images/` et tente d'y accéder via ton navigateur. Si le serveur renvoie une **Erreur 403 (Interdit), 404 (non trouvé) voire une redirection vers la page d'accueil**, ton dossier est parfaitement étanche ! *(N'oublie pas de supprimer le fichier de test ensuite).*

 
## 4. Exploiter le pare-feu de l'hébergeur (WAF)

 Certains hébergeurs proposent des pare-feu applicatifs intégrés au niveau de leur infrastructure (comme *Tiger Protect* chez o2switch).

 
- Ces WAF (Web Application Firewalls) filtrent le trafic malveillant, les injections SQL et les tentatives d'exploit **en amont**, avant même que la requête ne touche ton code PHP.
- Ils ne consomment aucune ressource sur ton serveur. Assure-toi que ces protections sont bien activées dans l'espace client de ton hébergeur.

 
## 5. Renforcer le navigateur client : En-têtes HTTP et CSP

 Le pare-feu protège le serveur, mais les en-têtes HTTP protègent tes visiteurs et l'affichage de ton site.

 Depuis **Joomla 4 et 5**, le plugin nativement intégré **Système - En-têtes HTTP** (*System - HTTP Headers*) permet de configurer facilement ces protections :

 
- **HSTS (`Strict-Transport-Security`) :** Force la connexion en HTTPS.
- **`X-Content-Type-Options: nosniff` :** Empêche le navigateur d'exécuter un fichier dont le type MIME est falsifié.
- **`X-Frame-Options: SAMEORIGIN` :** Empêche l'intégration de ton site dans des frames tiers (protection contre le Clickjacking).
- **Content Security Policy (CSP) :** C'est la protection ultime contre le XSS. La CSP indique au navigateur quels scripts, styles et images il a le droit d'exécuter.

 
- *Astuce :* Active d'abord la CSP en mode **Rapport uniquement** (*Report Only*) pour vérifier dans la console F12 de ton navigateur qu'aucun script légitime de ton site n'est bloqué, puis bascule en mode **Actif** (*Enforce*).

 Plus d'informations sur le plugin "En-têtes http" sur les [forums de Joomla](https://forum.joomla.fr/forum/joomla-3-x/questions--g%C3%A9n%C3%A9rales/1992243-plugin-httpheader). 

 
## Annexe

 
### 1. Les sauvegardes hors-site et leur restauration (DDR)

 
- **Le point clé :** Une sauvegarde ne sert à rien si elle reste sur le même serveur que le site web (car en cas d'attaque totale ou d'infection, la sauvegarde est compromise aussi).
- **Conseil :** Rappeler d'exporter automatiquement les sauvegardes (ex: via ***Akeeba Backup***) vers un stockage distant isolé (S3, Dropbox, serveur distant) et surtout **de tester la restauration de temps à autres**.

 
### 2. Le nettoyage des traces post-installation

 
- **Le point clé :** Beaucoup de webmasters laissent traîner des fichiers temporaires ou d'installation après des interventions.
- **Conseil :** Penser à supprimer les fichiers `.zip` d'installations, les scripts de migration ou les dossiers d'installation s'il y en a eu.

 
### 3. La gestion des comptes utilisateurs / Super Administrateurs

 
- **Le point clé :** L'accumulation de comptes inutilisés.
- **Conseil :** Faire un tri périodique : supprimer ou passer en "Bloqué" les comptes de développeurs, stagiaires ou prestataires qui n'ont plus lieu d'accéder au site.

 Un site ainsi configuré résistera à la quasi-totalité des attaques automatisées qui ravagent actuellement le Web !

 ## En résumé : La checklist d'un site Joomla incassable

 
1. Accès hébergeur sécurisé par 2FA/Passkeys + FTP désactivé.
2. Administration Joomla protégée par `.htpasswd` et 2FA.
3. Joomla et Extensions à jour.
4. Mises à jour automatisées via Panopticon ou outil équivalent.
5. Dossier `/images` verrouillé contre l'exécution de scripts PHP.
6. WAF de l'hébergeur activé.
7. En-têtes de sécurité HTTP et CSP configurés via le plugin natif de Joomla.

 
### Quelques outils de protection supplémentaires :

 Composant [CG Secure](https://www.conseilgouz.com/composant-cg-secure) par pmleconte, très actif sur les [forums francophone de Joomla](https://forum.joomla.fr/).  
Tu trouveras également de nombreux outils concernant la sécurité sur le [Joomla! Extensions Directirory™](https://extensions.joomla.org/category/access-a-security/).


## Champs personnalisés

**IA-Assistance:** Contenu rédigé à l'aide d'une assistance par IA. Relu, adapté et validé.

