T ToutadminDocumentazione

Questa pagina non è ancora tradotta nella tua lingua: è mostrata in francese.

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.

La session suit les droits réels

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, secure en production, identifiant régénéré à la connexion.

Attaques courantes#

RisqueMesure
Injection SQLRequêtes intégralement paramétrées (better-sqlite3)
XSShelmet avec CSP stricte : scripts par nonce, aucun style ni gestionnaire d'événement en ligne
CSRFJeton par session vérifié en comparaison à temps constant sur chaque POST
Force brute5 échecs consécutifs verrouillent le compte 15 minutes
Débit10 tentatives de connexion / 15 min par IP, 300 requêtes / minute au global
Énumération de comptesMessage et temps de réponse identiques que le compte existe ou non
Redirection ouverteToute cible venue d'un formulaire passe par un filtre qui refuse //site et /\site
Fichier hostileLa signature du fichier est vérifiée, pas le type MIME déclaré par le client
Fuite d'informationAucune trace technique renvoyée au client
Mauvaise configurationRefus 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.

Ce que le scellement ne fait pas

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.
Plusieurs administrateurs

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#

Aucun système n'est protégé de façon absolue

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à.

Documentazione di Toutadmin — costruita il 2026-09-13. Sito autonomo, indipendente dal software.