Diese Seite ist noch nicht in Ihre Sprache übersetzt: sie wird auf Französisch angezeigt.
Sécurité
Le contrôle d'accès repose sur des garde-fous côté serveur, pas sur ce que l'interface choisit d'afficher. Chaque famille de routes porte le sien, et les droits sont relus à chaque requête.
Contrôle d'accès#
requireAdmin sur /admin/*, requireHR sur
/rh/*, requireEmployee sur /mon-espace/*,
requireManager sur /mon-equipe — ce dernier étant recalculé à
chaque requête d'après les rattachements réels.
Seul un administrateur peut accorder ou retirer l'accès RH, rattacher un manager, masquer un membre de l'annuaire ou configurer une messagerie.
Désactivation, fin de contrat, verrouillage, promotion et rétrogradation sont relus à chaque requête. Un départ coupe l'accès tout de suite, sans attendre l'expiration du cookie.
Mots de passe#
- Hachage
bcrypt, coût 12. - Politique appliquée partout : 12 caractères minimum, trois catégories parmi minuscules, majuscules, chiffres et symboles ; ni le nom ni l'identifiant, ni suite de clavier, ni mot de passe courant.
- Les mots de passe temporaires font 16 caractères, sont affichés une seule fois et doivent être remplacés avant d'ouvrir quoi que ce soit.
- Changer de mot de passe ferme les autres sessions.
- Aucun mot de passe d'outil tiers n'est stocké — seulement l'identifiant et l'URL.
Double authentification#
TOTP conforme à la RFC 6238 : mise en service par QR code, vérifiée par un premier code avant d'être activée, avec des codes de secours à usage unique. Un code faux compte comme un échec de connexion. L'instance peut l'exiger des administrateurs, ou de tout le monde.
L'administration peut réinitialiser la double authentification d'un membre — pour un téléphone perdu ; la personne devra la remettre en service.
Sessions#
- Persistées en base : elles survivent à un redémarrage, se voient dans la console et se révoquent d'un geste, par la personne elle-même ou par l'administration.
- Expiration par inactivité (
SESSION_IDLE_MINUTES, 60 min par défaut) doublée d'un plafond absolu (SESSION_MAX_HOURS, 12 h). - Cookie
httpOnly,sameSite=lax,secureen production, identifiant régénéré à la connexion.
Attaques courantes#
| Risque | Mesure |
|---|---|
| Injection SQL | Requêtes intégralement paramétrées (better-sqlite3) |
| XSS | helmet avec CSP stricte : scripts par nonce, aucun style ni gestionnaire d'événement en ligne |
| CSRF | Jeton par session vérifié en comparaison à temps constant sur chaque POST |
| Force brute | 5 échecs consécutifs verrouillent le compte 15 minutes |
| Débit | 10 tentatives de connexion / 15 min par IP, 300 requêtes / minute au global |
| Énumération de comptes | Message et temps de réponse identiques que le compte existe ou non |
| Redirection ouverte | Toute cible venue d'un formulaire passe par un filtre qui refuse //site et /\site |
| Fichier hostile | La signature du fichier est vérifiée, pas le type MIME déclaré par le client |
| Fuite d'information | Aucune trace technique renvoyée au client |
| Mauvaise configuration | Refus de démarrer en production si SESSION_SECRET ou ADMIN_PASSWORD sont restés par défaut |
Le cas des envois de fichiers#
Un envoi multipart pose un problème d'ordre : le jeton CSRF est dans le corps de la requête, donc il n'est lisible qu'une fois le corps décodé — c'est-à-dire une fois le fichier reçu. Le contrôle est donc différé juste après la réception, et les fichiers transitent en mémoire : rien n'est écrit sur le disque avant que le jeton soit validé.
Journal d'audit#
Toute requête qui modifie quelque chose est tracée : auteur, action, objet, adresse, horodatage. Les actions sensibles reçoivent des entrées détaillées — connexions réussies et manquées, réinitialisations, promotions, changements de politique, téléchargements du coffre, échecs d'intégrité.
Consultable, filtrable et exportable en CSV depuis /securite, purgeable selon la
durée de conservation choisie.
Scellement par chaînage d'empreintes#
Chaque entrée porte l'empreinte de la précédente. Modifier une ligne,
ou en retirer une du milieu, casse la chaîne à cet endroit — et la vérification
(/securite, onglet Scellement) dit lequel : elle nomme l'entrée, sa date,
et distingue un contenu modifié après coup d'une entrée qui a disparu. Les entrées
antérieures à la mise en service du scellement sont comptées à part plutôt que
présentées comme vérifiées.
Empêcher la réécriture. Qui tient le fichier de la base peut tout recalculer. Il rend l'altération visible, ce qui est ce qu'on attend d'un journal, et c'est aussi loin qu'on aille sans autorité d'horodatage extérieure. Une purge, elle, retire légitimement le début de la chaîne, et laisse sa propre entrée pour le dire.
Console de sécurité#
/securite, réservée à l'administration :
- Journal d'audit filtrable et exportable.
- Sessions ouvertes, et leur révocation.
- Comptes à surveiller : verrouillés, mot de passe temporaire jamais remplacé, administrateurs sans double authentification, comptes dormants depuis 90 jours.
- Gestion des administrateurs et politique de l'instance.
Une entreprise ne dépend pas d'un seul compte. Le dernier administrateur ne peut être ni rétrogradé, ni se retirer ses propres droits.
Données au repos#
- Secrets chiffrés en AES-256-GCM (mot de passe FTP, clé de compte de service, mot de passe IMAP, clé du service d'analyse, secret de webhook), avec une clé dérivée du secret de session qui vit dans un fichier à part.
- Jetons d'API jamais conservés en clair : seule leur empreinte SHA-256 vit en base.
- Documents scellés : coffre-fort et parapheur portent le SHA-256 de leur contenu, revérifié à chaque lecture.
- Fichiers hors du dépôt, en
0600: CV, coffre, parapheur, pièces reçues, sauvegardes. Seules les photos de profil sont servies en statique.
Ce que ces mesures ne couvrent pas#
Ces mesures couvrent les risques standards — injection, authentification, XSS, CSRF, contrôle d'accès, mauvaise configuration. Elles ne remplacent ni la sécurisation du serveur qui héberge l'instance, ni une politique de mots de passe côté humain, ni une sauvegarde recopiée hors de la machine.
Le chiffrement au repos protège les secrets rangés en base, pas la base entière : qui obtient une copie du fichier SQLite obtient les données métier. C'est le système de fichiers et le contrôle d'accès à la machine qui protègent ce niveau-là.
Toutadmin-Dokumentation — erstellt am 2026-09-13. Eigenständige Website, unabhängig von der Software.