---
title: "Sécurité"
description: "Pourquoi Éclair est un CMS sécurisé par défaut : sans base de données, Argon2id, double authentification, CSP stricte, contrôle d’intégrité et revue offensive."
url: "https://eclaircms.org/documentation/securite"
lang: "fr"
author: "Thierry Gustin"
published: "2026-10-30"
updated: "2026-10-30"
---

# Sécurité

> **L’essentiel** — Éclair est un CMS sécurisé par défaut : sans base de données, il n’offre aucune prise à l’injection SQL ; ses données sont doublement protégées ; la connexion combine Argon2id, anti-bruteforce et double authentification ; le site public applique une Content-Security-Policy stricte. Une revue de sécurité offensive a trouvé 17 failles, toutes corrigées.

Éclair est un CMS sécurisé par défaut, conçu pour un environnement hostile : un hébergement mutualisé et des robots qui testent des mots de passe en permanence. Tu n’as rien à installer ni à régler pour être protégé. Ce guide explique ce qui est verrouillé d’office, ce que l’administration surveille et les quatre gestes qui renforcent encore ton site.

## Pourquoi un site sans base de données est-il plus sûr ?

Sans base de données, l’injection SQL, l’une des attaques les plus répandues contre les sites web, n’a tout simplement rien à viser. Tes contenus sont des fichiers, et ces fichiers sont protégés deux fois :

- les dossiers `data/`, `app/` et `cache/` sont interdits depuis le web par le fichier `.htaccess` ;
- chaque fichier de données commence par la ligne `<?php exit; ?>` : même si un serveur ignorait les `.htaccess`, rien ne s’afficherait, et aucune séquence `<?php` ne peut y être écrite ;
- les fichiers sont privés (droits 0600) et écrits de façon atomique : une coupure ne laisse jamais un fichier à moitié écrit.

L’installation elle-même est protégée : elle n’est possible que dans les 2 heures qui suivent la première visite, et l’adresse du site n’est utilisée pour rediriger les visiteurs qu’après avoir été vérifiée par le serveur lui-même.

## Comment la connexion est-elle protégée ?

- **Mots de passe** chiffrés avec Argon2id (19 Mio de mémoire, 2 passes), les paramètres recommandés par l’[OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) ; bcrypt en repli. 10 caractères minimum, mots de passe courants refusés.
- **Anti-bruteforce** : chaque tentative est réservée avant d’être vérifiée, ce qui rend impossible de dépasser la limite en parallèle. Les limites portent sur le réseau (adresse IPv4 ou bloc /64 en IPv6) et sur le compte visé. Ton appareil habituel n’est jamais bloqué par un attaquant qui se trompe exprès.
- **Double authentification** (2FA) compatible Google Authenticator, Microsoft Authenticator, 1Password ou Bitwarden, avec QR code et 8 codes de secours affichés une seule fois. Après 10 codes faux, la 2FA du compte est bloquée 15 minutes et son titulaire est prévenu par e-mail.
- **Mot de passe redemandé** pour les actions sensibles (sauvegarde, comptes, réglages avancés, changement d’e-mail) au-delà de 15 minutes après la connexion.
- **Sessions durcies** : aucune session avant la connexion, cookies `HttpOnly`, `Secure` et `SameSite=Strict`, déconnexion après inactivité, bouton « Déconnecter tout le monde ». L’administration est forcée en HTTPS dès que le site l’est.
- **Jetons CSRF** sur toutes les actions, et vérification de l’origine des requêtes.

## Comment le site public est-il verrouillé ?

| Protection | Ce qu’elle empêche |
| --- | --- |
| Content-Security-Policy stricte (aucun script en ligne, empreinte SHA-256 pour le style) | L’exécution de scripts injectés |
| Anti-clickjacking, `nosniff`, `Referrer-Policy`, `Permissions-Policy`, HSTS en option | L’intégration piégée, les fuites d’informations |
| Aucune redirection ouverte | L’usage de ton domaine pour rediriger vers un site malveillant |
| Contenus assainis par liste blanche | Les liens `javascript:` ou `data:`, même déguisés |
| Formulaire de contact avec champ piège, jeton et limites | Le spam, sans captcha : 5 messages par réseau toutes les 10 minutes, 100 par jour pour tout le site |
| Images ré-encodées à l’envoi | Les charges cachées et les données EXIF ou GPS ; les SVG et les images contenant du code sont refusés |

Les en-têtes de sécurité dépendent des réglages, jamais de la requête : une page servie depuis le cache envoie les mêmes à tout le monde, ce qui rend l’empoisonnement du cache impossible.

## Que surveille la page Sécurité ?

Réservée aux administrateurs, la page **Sécurité** rassemble tes outils de contrôle :

![Page Sécurité de l’administration d’Éclair : niveau de protection en pourcentage, test de protection des dossiers et contrôle d’intégrité](https://eclaircms.org/media/2026/10/page-securite.webp)
*La page Sécurité : chaque point orange indique une protection que tu peux encore activer.*

1. **Niveau de protection** : un pourcentage et l’état de chaque protection (HTTPS, adresse vérifiée, double authentification, adresse d’administration, version de PHP, HSTS…), avec le bouton **Vérifier l’adresse du site**.
2. **Test de protection des dossiers** : ton navigateur tente d’ouvrir des fichiers internes, qui doivent rester inaccessibles.
3. **Intégrité des fichiers** : chaque fichier d’Éclair est comparé à son empreinte d’origine, et les fichiers suspects sont signalés, comme un script caché dans les médias ou un `.php` sans ligne de protection dans `data/`.
4. **Sauvegarde** : une archive de tout ton site en un clic.
5. **Sessions et blocages**, puis le **journal de sécurité** : connexions, échecs, blocages, changements de mot de passe, sauvegardes.

Les journaux sont bornés à 1 Mo : impossible de les faire gonfler pour remplir le disque.

## Qu’a révélé la revue de sécurité offensive ?

Avant sa publication, Éclair a été attaqué méthodiquement : courses entre requêtes, force brute, redirections, injections, fichiers piégés. **17 failles** ont été trouvées, dont 2 graves, 7 moyennes et 8 mineures, et toutes ont été corrigées. Les 13 scénarios d’attaque ont ensuite été rejoués sur la version corrigée : tous neutralisés. L’assistant IA, arrivé avec la version 1.2.0, a eu sa propre revue avant sa sortie.

Les tests automatiques d’Éclair, qui comptent 299 vérifications, reprennent une grande partie de ces attaques. Le détail des correctifs figure dans le [journal des versions](https://eclaircms.org/changelog).

## Quels gestes renforcent encore ton CMS sécurisé ?

> **Les 4 gestes qui comptent** — 1. Active la **double authentification** dans Mon profil, pour chaque administrateur.  
> 2. Choisis une **adresse d’administration personnalisée** dans Réglages › Avancé : moins de robots frapperont à la porte.  
> 3. Clique sur **Vérifier l’adresse du site** dans Sécurité, puis active HSTS quand le HTTPS fonctionne parfaitement.  
> 4. **Télécharge une sauvegarde** avant chaque grosse modification, dans Sécurité › Sauvegarde.

Garde aussi PHP à jour chez ton hébergeur : Éclair fonctionne de PHP 8.1 à 8.5, et 8.3 est recommandé. Pour la sauvegarde et les mises à jour, voir le guide [Mettre à jour, sauvegarder, déménager](https://eclaircms.org/documentation/mise-a-jour).

## Questions sur la sécurité

### Éclair est-il vraiment un CMS sécurisé sans extension de sécurité ?

Oui. Double authentification, anti-bruteforce, en-têtes stricts, contrôle d’intégrité et sauvegarde sont intégrés. Sans extensions à mettre à jour, la première source de failles des CMS classiques disparaît. Le [comparatif avec WordPress](https://eclaircms.org/eclair-vs-wordpress) chiffre cet écart.

### J’ai perdu mon téléphone de double authentification : que faire ?

Utilise l’un de tes 8 codes de secours. Si tu les as perdus et qu’aucun autre administrateur ne peut t’aider, suis la procédure de secours par FTP décrite dans [Dépannage](https://eclaircms.org/documentation/depannage#mot-de-passe-oublie).

### Un attaquant peut-il bloquer mon compte en se trompant exprès ?

Non : ton appareil habituel n’est jamais bloqué par les échecs d’un autre. Les limites visent le réseau de l’attaquant et le compte, sans t’empêcher de te connecter depuis chez toi.

### Que faire si le contrôle d’intégrité signale un fichier modifié ?

Si tu n’as rien personnalisé, remplace le fichier par celui de l’archive officielle. Si tu as modifié ton thème, c’est normal : les fichiers de app/theme apparaissent comme modifiés.