Journal d'audit — la mémoire des décisions de sécurité

stable@nodefony/securitymis à jour 2026-07-19

Chaque fois qu’une décision de sécurité est prise — un login réussit, un accès est refusé, une clé d’API est révoquée, un jeton volé resurgit — Nodefony écrit une ligne dans un journal append-only : qui, quoi, quand, d’où, avec quel verdict. Pas le trafic (ça, c’est le log HTTP) : les transitions d’état. Ancré sur AuditService (^{auditService.ts:48}), le contrat IAuditEvent (^{IAuditEvent.ts:53}) et les stores de nodefony/src/audit/.

📍 Documentation › Sécurité › Journal d’audit

🧠 Le modèle mental — deux journaux, deux métiers#

Un serveur produit deux flux d’écriture, et les confondre coûte cher. Le log de trafic répond à « que s’est-il passé sur le réseau ? » ; le journal d’audit répond à « qui a obtenu quoi, et pourquoi ? ».

AuditService.record() (^{auditService.ts:180}) est le point de passage unique : il pose l’identité et l’horodatage, écrit sans attendre, et notifie les abonnés live. Tout le reste — stores, pont WS, webhooks, console — se branche autour de lui.

📖 Lexique#

Qu’est-ce qu’un journal d’audit — et quelle faille il ferme#

Un journal d’audit est le magnétoscope des décisions de sécurité. Il n’empêche aucune attaque : il rend l’attaque racontable après coup.

La faille qu’il ferme n’est pas une injection, c’est le trou noir : sans journal, une intrusion est indétectable et indémontrable. Concrètement, sans lui :

• une attaque par force brute ressemble à du trafic normal — personne ne voit les 4 000 login.failure de la nuit ;
• un jeton volé rejoué passe inaperçu, alors que c’est le signal d’attaque le plus fort qui soit ;
• une escalade de privilèges ne laisse aucune trace exploitable : impossible de dire quel compte a tenté quoi, ni depuis quelle IP ;
• face à un auditeur (ISO 27001, SOC 2, RGPD), tu ne peux rien prouver — ni que les accès sont contrôlés, ni qu’un refus a bien eu lieu.

C’est la raison d’être des exigences de journalisation de l’OWASP Logging Cheat Sheet et de l’entrée A09:2021 – Security Logging and Monitoring Failures du Top 10 : l’absence de trace est elle-même classée comme une vulnérabilité.

La vision Nodefony#

Trois partis pris, tous vérifiables dans le code.

1. Le journal trace les transitions, jamais le trafic. Le succès nominal est muet : une requête authentifiée qui passe n’écrit rien. Prouvé par les tests « SUCCÈS authentifié → AUCUNE émission » (^{auditEmissionHotPath.test.ts:229}) et « SUCCÈS anonyme EXPLICITE → AUCUNE émission » (^{auditEmissionHotPath.test.ts:243}). Conséquence directe : ce que tu lis dans le journal est un signal, pas du bruit à filtrer.

2. L’audit ne peut jamais casser le métier. record() est synchrone, sans await, et l’écriture part en fire-and-forget avec un .catch() qui se contente de logger (^{auditService.ts:192}). Un store en panne dégrade la traçabilité, il ne renvoie pas 500 à l’utilisateur.

3. Le store est pluggable, jamais câblé en dur. Le service résout un nom via un registre (getAuditStoreFactory(), ^{auditStoreRegistry.ts:48}) ; le socle n’embarque que le builtin mémoire, posé par registerAuditStore("memory") à l’import (^{auditStoreRegistry.ts:64}), et les backends lourds s’enregistrent depuis leur module. Un if (name === "drizzle") dans le service trahirait la promesse.

🚀 Démarrage rapide#

Dans une app générée par nodefony create app, l’audit est déjà actif (enabled: true par défaut, ^{config.ts:729}) sur un store mémoire. Voici le parcours complet : configurer, émettre, relire.

1. Choisir où le journal est écrit#

// nodefony.config.ts (extrait) — le journal survit au redémarrage et se partage entre pods
use("@nodefony/security", {
  audit: {
    // "auto" (défaut) suit l'infra database déclarée ; "drizzle" force le SQL.
    // "memory" = volatile et per-pod : parfait en dev, jamais en production.
    store: "drizzle",
    // Rétention : au-delà, la purge horaire supprime. Défaut 365 jours.
    retentionDays: 90,
  },
});

Rien d’autre à écrire : l’adapter @nodefony/drizzle déclare l’entité et la fabrique de store tout seul au démarrage (^{registerStores.ts:241}).

2. Émettre un événement depuis ton code#

recordAudit() (^{recordAudit.ts:15}) est exporté par le module. Il est no-op si l’audit est absent ou désactivé — tu peux l’appeler sans garde.

// nodefony/controllers/ExportController.ts — complet, compile tel quel
import {
  controller,
  Controller,
  Post,
  IsGranted,
  CurrentUser,
} from "@nodefony/framework";
import { recordAudit } from "@nodefony/security";
import type { IUser } from "@nodefony/user";

@controller("/api/back/export")
class ExportController extends Controller {
  @IsGranted(["ROLE_ADMIN"])
  @Post("/customers")
  async exportCustomers(@CurrentUser() user: IUser) {
    // L'export de données clients est une action sensible : elle DOIT laisser une trace.
    recordAudit(this.container, {
      category: "authz", // union fermée — voir le catalogue plus bas
      action: "data.exported", // chaîne libre, convention <sujet>.<verbe>
      outcome: "success",
      actor: user.identifier, // un libellé d'identité, JAMAIS un secret
      resource: "customers",
      reason: "admin_export",
      metadata: { rows: 4213 }, // extras applicatifs libres
    });
    return this.renderJson({ exported: 4213 });
  }
}

export default ExportController;

❗ Important

category est une union fermée de sous-systèmes de sécurité (^{IAuditEvent.ts:16}) : il n’existe pas de catégorie « métier ». C’est volontaire — ce journal est celui de la sécurité. Range ton événement dans la catégorie de sécurité qu’il concerne (ici authz : un accès privilégié à des données) et laisse action porter le vocabulaire métier.

3. Relire le journal#

Le data plane d’admin sert une page filtrée, réservée à ROLE_NODEFONY_ADMIN (^{SecurityAdminApi.ts:331}) :

# Les échecs d'authentification d'un compte, sur une fenêtre donnée
curl -s -b /tmp/jar \
  'http://localhost:5151/nodefony/security/api/audit/events?category=auth&outcome=failure&actor=alice&limit=50'

Ce qu’on observe#

{
  "items": [
    {
      "id": "9f3ac21b-1",
      "ts": 1763548800123,
      "category": "auth",
      "action": "auth.failure",
      "outcome": "failure",
      "actor": "alice",
      "resource": "nodefony-admin",
      "reason": "invalid_credentials",
      "ip": "203.0.113.9",
      "userAgent": "curl/8.6.0",
      "requestId": "req-7c1e",
      "flags": { "hasAuthorization": true, "hasCookie": false }
    }
  ],
  "limit": 50,
  "hasNext": true,
  "nextCursor": "1763548800123:9f3ac21b-1",
  "total": 137
}

Trois choses à remarquer : le motif machine (reason) est filtrable, la provenance est là sans qu’on l’ait demandée (IP, User-Agent, requestId), et les flags disent qu’un en-tête Authorization était présent — sans jamais donner sa valeur.

Le même journal est consultable dans Studio → Sécurité → Journal d’audit.

⚙️ Quatre situations — du besoin à la config#

Situation 1 — « Qui s’est connecté à ce compte cette nuit ? »#

Un utilisateur signale une activité suspecte sur son compte. Tu veux la liste des tentatives, réussies et ratées, sur une fenêtre précise.

Aucune configuration : les événements d’authentification sont émis par défaut. Il suffit de filtrer. Les critères se combinent en ET et sont traduits par parseAuditQuery() (^{SecurityAdminApi.ts:191}) :

# La nuit de 02:00 à 08:00, tout ce qui concerne alice
curl -s -b /tmp/jar 'http://localhost:5151/nodefony/security/api/audit/events\
?actor=alice&since=1763517600000&until=1763539200000&limit=200'

Ce qu’on observe : les login.success et login.failure avec leur IP, et un auth.throttled si le backoff NIST s’est déclenché — la signature d’une attaque par essais répétés.

Situation 2 — « Prouver à un auditeur qu’un accès refusé a bien été tracé »#

Un auditeur demande la preuve que le contrôle d’accès n’est pas décoratif.

Le jury d’autorisation journalise tout refus et seulement les refus, par un appel à recordAudit() (^{authorization.ts:130}) : les octrois restent muets, parce qu’un octroi est du volume, pas un signal.

curl -s -b /tmp/jar \
  'http://localhost:5151/nodefony/security/api/audit/events?outcome=denied&limit=100'

Ce qu’on observe : des access.denied dont le champ resource porte l’attribut exigé (ROLE_ADMIN, doc.edit…) et reason le motif du jury (veto, silence des voters). Le requestId permet de recoller l’événement à la trace complète de la requête.

💡 Astuce

Le refus au niveau du firewall (401) et le refus au niveau de l’autorisation (403) sont deux événements différents : auth.denied (catégorie auth) contre access.denied (catégorie authz). Filtrer sur category=authz&outcome=denied isole exactement « quelqu’un d’authentifié a tenté ce qu’il n’avait pas le droit de faire » — le signal d’escalade de privilèges.

Situation 3 — « Garder 90 jours sans faire exploser la base »#

Ta politique de conservation impose 90 jours, pas plus (minimisation RGPD) et pas moins (obligation de preuve).

use("@nodefony/security", {
  audit: { store: "drizzle", retentionDays: 90 },
});

Ce que ça déclenche : le service arme un GcScheduler de purge toutes les heures (^{auditService.ts:152}, intervalle GC_INTERVAL_MS — ^{auditService.ts:31}), avec gigue anti-avalanche en cluster. Chaque tour appelle la purge du contrat — gc(), voisin de listPage() dans le même contrat (^{IAuditStore.ts:67}) — qui supprime les événements plus vieux que la fenêtre : un DELETE par seuil côté SQL (^{DrizzleAuditStore.ts:231}), un défilement de file tant que l’événement de tête dépasse le threshold côté mémoire (^{MemoryAuditStore.ts:127}).

Ce qu’on observe dans les logs : audit gc — 1284 événement(s) purgé(s) en niveau DEBUG.

Le store mémoire porte une seconde protection, indépendante du temps : un plafond de 10 000 entrées en FIFO (^{MemoryAuditStore.ts:10}, appliqué à ^{MemoryAuditStore.ts:59}). Ce n’est pas une politique de rétention, c’est un garde-fou anti-fuite : la mémoire d’un pod est bornée quoi qu’il arrive.

Situation 4 — « Ne rien perdre quand le store tombe »#

La base est indisponible pendant trente secondes. Que se passe-t-il ?

Le choix de Nodefony est explicite : le métier passe avant la trace. L’écriture part en fire-and-forget — append() sans await, échec absorbé en log ERROR (^{auditService.ts:192}) ; côté SQL, si l’ORM n’est pas connecté, append() est un no-op assumé (^{DrizzleAuditStore.ts:131}). Un login n’échoue jamais parce que le journal est cassé.

⚠️ Attention

Le corollaire est une perte possible d’événements pendant une panne du store. Le contrat est best-effort, pas transactionnel : il n’existe pas de tampon de reprise ni de journal d’écriture anticipée. Si ta conformité exige « aucune action sans trace », il faut un store à haute disponibilité — le contrat IAuditStore (^{IAuditStore.ts:48}) est le point d’extension pour ça.

Deux garde-fous limitent la casse au démarrage : un store explicitement configuré mais inconnu avorte le boot en production (^{auditService.ts:109}), et un store memory en production déclenche un WARNING nommant précisément le risque — volatil, per-pod, rétention réglementaire impossible (^{auditService.ts:122}).

🔐 Le catalogue des événements audités#

Deux axes de classement. La catégorie est une union fermée (^{IAuditEvent.ts:16}) : c’est l’axe de filtrage principal de la console. L’action est une chaîne ouverte (^{IAuditEvent.ts:66}) : la liste grandit sans jamais casser le contrat.

Vue d’ensemble — choisir son filtre en cinq secondes#

<!-- prettier-ignore -->

Les trois issues possibles (^{IAuditEvent.ts:35}) ne sont pas interchangeables : failure = l’acteur a échoué une preuve (mauvais mot de passe, signature invalide) ; denied = une politique a refusé un acteur pourtant bien formé (Zero Trust, rôle manquant) ; success = l’action a abouti. Pour un auditeur, la colonne denied est celle des tentatives d’accès non autorisé.

🧰 Le contrat d’une entrée#

Un événement est un objet sérialisable JSON (^{IAuditEvent.ts:53}). L’émetteur ne fournit qu’un brouillon IAuditEventDraft (^{IAuditEvent.ts:105}) : id et ts sont posés par le service, ce qui garantit un seul appel d’horloge, centralisé hors des points d’émission.

Les quatre derniers champs de provenance sont remplis d’un coup par readAuditContext() (^{readAuditContext.ts:33}), qui lit un contexte HTTP ou WS de façon défensive — tous les champs sont optionnels, un contexte partiel ne casse rien.

⚡ Performance & mémoire — pourquoi l’audit ne pèse pas sur la requête#

C’est un point d’honneur du framework : l’audit ne se paie que quand il se passe quelque chose. Quatre mécanismes, tous prouvés par les tests.

1. Le chemin nominal n’émet rien. Ce n’est pas une optimisation, c’est le modèle : le firewall n’appelle #recordAuth() que depuis ses quatre sorties d’échec, jamais depuis le succès (^{firewall.ts:884}). Le verrou WS ne tire sa closure onDeny que sur refus (^{firewall.ts:341}). Prouvé : « frame AUTORISÉE → onDeny JAMAIS appelé » (^{auditEmissionHotPath.test.ts:324}).

2. Audit désactivé = coût nul, pas juste coût faible. record() sort avant toute allocation et avant tout appel d’horloge si le service est inactif (^{auditService.ts:182}). Aucun objet créé, aucun appel d’horloge. Prouvé par le banc « audit désactivé → issueTokens n’est pas journalisé » (^{auditEmissionHotPath.test.ts:499}).

3. L’écriture ne bloque pas. append() part sans await, avec un .catch() qui logge (^{auditService.ts:192}). La latence du store n’entre jamais dans la latence de la requête.

4. Tout ce qui n’est pas utilisé n’est pas alloué. La liste d’abonnés live reste null tant que personne n’écoute et redevient null au dernier désabonnement (^{auditService.ts:221}). Le pont WS n’existe qu’entre le premier et le dernier auditeur connecté, et son tampon circulaire n’est alloué qu’au premier événement reçu (^{auditBridge.ts:62}) ; son minuteur est armé à la demande et unref (^{auditBridge.ts:93}).

Le pont applique en plus un coalescing borné : au plus une frame WS toutes les 250 ms (^{auditBridge.ts:59}), tampon plafonné à 200 événements (^{auditBridge.ts:60}). Sous une rafale d’échecs de login, le tampon écrase les plus anciens et compte les omis dans dropped (^{auditBridge.ts:84}) — la console affiche un récapitulatif au lieu de se figer. Superviser ne doit jamais faire tomber ce qu’on supervise.

⚙️ Configuration#

Table dérivée du schéma Zod auditSchema (^{config.ts:877}), rattaché à la racine sous la clé audit (^{config.ts:1121}).

⚠️ Attention

immutable et stream sont déclarés dans le schéma mais ne sont lus par aucun code aujourd’hui. Les mettre à false ne change rien. L’immuabilité vient du contrat IAuditStore, qui n’expose ni update ni delete ciblé (^{IAuditStore.ts:48}) ; la diffusion live est gouvernée par la présence d’abonnés — la liste #listeners du service (^{auditService.ts:194}).

Comment store: "auto" décide#

Le défaut ne suppose rien : il suit l’infrastructure déclarée, borné aux backends réellement enregistrés (^{auditService.ts:92}, logique resolveAutoStore() dans ^infra.ts:241).

1. NF_STORE posée et le backend est enregistré pour l’audit → il gagne (levier de banc de charge) ;
2. sinon, une base est déclarée (NF_DATABASE_URL) → drizzle, ou mongoose selon la famille ;
3. sinon, repli annoncé sur memory — la décision est loggée en INFO, jamais silencieuse.

La résolution finale est publiée au kernel (^{auditService.ts:139}), ce qui alimente l’écran des stores de Studio : configuré, résolu, disponible, motif, emplacement physique.

🏗️ Architecture interne#

Quatre pièces, quatre responsabilités :

• recordAudit() (^{recordAudit.ts:15}) — le point d’émission côté appelant. Une résolution par le container, sur le cold-path uniquement. C’est ce qui rend l’audit découplé : module absent → aucun effet, jamais d’exception qui remonterait dans le flux métier.
• AuditService (^{auditService.ts:48}) — le propriétaire. Il construit le store au boot, le pose au container sous le nom auditStore (^{auditService.ts:138}), arme la purge, et implémente IAuditSink (^{IAuditStore.ts:77}).
• IAuditStore (^{IAuditStore.ts:48}) — le contrat de persistance : append, listPage, gc. append est la seule écriture : ni update, ni delete ciblé. L’immuabilité EST la garantie d’audit.
• createAuditBridge() (^{auditBridge.ts:53}) — le pont vers le canal WS nodefony:audit (^{auditBridge.ts:8}), enregistré comme canal système par le firewall (^{firewall.ts:322}) et donc gardé par le plancher security: → ROLE_NODEFONY_ADMIN (^{frameAuthorizer.ts:106}).

La lecture paginée — pourquoi un curseur et pas un décalage#

Un journal reçoit des écritures pendant qu’on le parcourt. Un OFFSET 200 glisserait d’une page à l’autre : on reverrait des événements déjà lus, on en manquerait d’autres. Le contrat impose donc le curseur (^{IAuditStore.ts:22}).

Le curseur est composite et auto-portant : <ts>:<id>. Deux propriétés que les deux backends tiennent identiquement :

• ordre total — l’horodatage porte la chronologie, l’identifiant départage les collisions à la milliseconde. Sans ce tri desc(ts), desc(id), trois échecs de login de la même milliseconde pourraient se répéter ou disparaître (^{MemoryAuditStore.ts:83}, ^{DrizzleAuditStore.ts:197}) ;
• auto-portance — le jeton contient tout ce qu’il faut pour se comparer, donc une page reste juste même si l’événement qui l’a produite a été purgé entre-temps (^{MemoryAuditStore.ts:115}, ^{DrizzleAuditStore.ts:219}). Un curseur réduit à un identifiant nu aurait rembobiné en silence à la première page — et fait boucler la console.

Le total est refusable (withTotal: false) : un COUNT filtré sur une rétention longue se paie (^{IAuditStore.ts:59}). hasNext et nextCursor restent fiables dans les deux cas, grâce à une ligne de garde limit + 1 (^{DrizzleAuditStore.ts:198}).

Entité de persistance et dialectes pris en charge#

Un seul backend durable est fourni : @nodefony/drizzle. Le décompte honnête :

Mongoose porte session, user, jetons, passkeys et webhooks, mais pas l’audit ; Redis non plus. Ces deux absences n’ont pas le même statut. Redis n’en aura pas, et la raison n’est pas « c’est un cache » — il porte déjà des données durables comme les passkeys, en opt-in assumé. C’est que le journal d’audit croît sans borne, se conserve des mois pour la conformité, et se consulte (recherche, filtres, pagination) : garder tout ça en mémoire vive coûte cher pour un motif d’accès qui n’est pas le sien. Mongo, lui, est un chemin durable : l’audit y manque, et c’est un manque à combler (objectif « full NoSQL », MIGRATION_STATUS.md P7.11) — un utilisateur choisit sa base de données, pas de perdre sa traçabilité.

En attendant, une application MongoDB qui veut un journal durable a trois voies : brancher un store maison (voir l’extension ci-dessous), charger @nodefony/drizzle à côté de Mongo — même en SQLite local, les deux modules cohabitent — ou héberger le journal sur une base SQL.

La table audit_event#

L’entité est déclarée en spécification logique (^{auditEventEntity.ts:37}), déclinée par dialecte via le colKit — mêmes noms de colonnes partout, donc un store dialect-agnostique. La forme de ligne AuditEventRow (^{auditEventEntity.ts:85}) est identique au contrat IAuditEvent, champ pour champ : aucun mapping surprise.

En MySQL, toute colonne texte indexée (ou clé primaire) devient varchar(512) : InnoDB ne sait pas indexer un TEXT sans longueur de préfixe. Même règle pour tout le framework, portée par le colKit — jamais par l’entité.

Quatre index couvrent les axes de la console (^{auditEventEntity.ts:61}) : ts pour la pagination chronologique, category, actor et requestId pour les filtres. Ils sont lus par drizzle-kit pour les migrations de production ; en dev et en test, le DDL dérivé les ignore — pure performance de filtrage, jamais de sémantique.

L’entité et la fabrique sont enregistrées automatiquement par l’adapter au démarrage (^{registerStores.ts:241}, entité via registerAuditEntities(), ^{auditEventEntity.ts:141}). Côté implémentation, DrizzleAuditStore (^{DrizzleAuditStore.ts:64}) résout son handle de base à chaque appel, pas à la construction : l’ordre de démarrage n’est pas garanti, et l’ORM se déconnecte au onTerminate avant le drain des serveurs.

🔐 Sécurité — ce qui n’entre JAMAIS dans le journal#

La règle d’or est écrite en tête du contrat (^{IAuditEvent.ts:8}) : un secret n’entre jamais dans un événement. Ni mot de passe, ni jeton, ni cookie, ni corps de requête, ni en-têtes.

Ce que le code garantit, concrètement :

• Le typage rend le secret difficile à faire entrer. actor est documenté comme un libellé d’identité (^{IAuditEvent.ts:74}) et resource comme un descripteur léger — « jamais le corps ni les en-têtes de la requête » (^{IAuditEvent.ts:79}).
• La présence remplace la valeur. IAuditEventFlags (^{IAuditEvent.ts:41}) ne porte que deux booléens : un en-tête Authorization était-il là, un cookie était-il là. readAuditContext() les calcule par un simple Boolean(headers[…]) (^{readAuditContext.ts:40}) — la valeur n’est jamais copiée.
• Les émetteurs journalisent l’identifiant public, pas le secret. Une clé d’API émet son id public en resource, jamais le jeton. Prouvé explicitement : le test vérifie que la sérialisation complète de l’événement ne contient pas le secret créé (^{auditEmissionHotPath.test.ts:545}).
• Le motif reste machine. reason est une valeur stable et filtrable, pas un message d’erreur libre (^{IAuditEvent.ts:84}) : c’est ce qui empêche une cause fine de fuir dans la trace… et qui permet de la garder côté audit alors que le client, lui, reçoit un message d’échec uniforme (anti-énumération).

Deux autres propriétés de sécurité valent d’être connues :

• Pas d’événement fantôme. Révoquer la clé d’API d’autrui n’émet rien : l’anti-énumération vaut aussi pour le journal, sinon le journal lui-même deviendrait un oracle (^{auditEmissionHotPath.test.ts:561}).
• Lecture réservée aux administrateurs. L’endpoint est gardé ROLE_NODEFONY_ADMIN, le canal live aussi via le plancher irréductible security: (^{frameAuthorizer.ts:107}) — un utilisateur ordinaire qui tente de s’y abonner produit lui-même un frame.denied.

📜 Normes appliquées#

📡 Observabilité — Studio#

L’écran Sécurité → Journal d’audit (/nodefony/audit) (^Audit.tsx:62) consomme le data plane GET /nodefony/security/api/audit/events en pagination serveur. Il offre :

• un tableau filtrable par heure, catégorie, action, issue, acteur, raison et IP (^{Audit.tsx:227}) ;
• un indicateur du store réellement résolu pour la brique audit, alimenté par la publication de résolution du service (^{auditService.ts:139}) ;
• un interrupteur Temps réel qui s’abonne au canal nodefony:audit (^{AuditLive.tsx:20}) — pensé pour les pics d’activité : un journal d’audit se consulte, il ne se regarde pas défiler ;
• un renvoi vers la trace de requête quand l’événement porte un requestId, ce qui recolle l’événement de sécurité à toute la vie de la requête.

Quand l’audit est désactivé en configuration, l’endpoint répond 503 avec un message explicite (^{SecurityAdminApi.ts:341}) et la console l’affiche tel quel plutôt qu’un tableau vide ambigu.

Le journal alimente les webhooks#

Le flux d’audit est la source d’événements du dispatcher de webhooks sortants : celui-ci s’abonne au service au démarrage (^{webhooks.ts:214}) et filtre les actions souscrites avant de livrer (^{WebhookDispatcher.ts:132}). Conséquence pratique : ce qui n’est pas audité ne peut pas déclencher de webhook. Détail des souscriptions, de la signature et des relivraisons → webhooks.

⚠️ Pièges#

🧪 Tests & couverture#

Les chiffres exacts vivent dans la carte de l’aperçu (régénérée depuis vitest, jamais figée ici). Cinq familles couvrent la brique :

• unit — le socle : auditService (store mémoire append-only, filtres, curseur, borne de volume, purge, instantané ; et côté service : no-op à coût nul, estampille id+ts, diffusion live, isolation d’un abonné qui lève) ; auditStoreRegistry (builtin enregistré à l’import, fabrique défensive sur config partielle, backend inconnu) ; auditBridge (coalescing borné, nettoyage, plancher ROLE_NODEFONY_ADMIN du canal).
• unit — l’émission : auditEmission prouve que AuthFlow et Authorization journalisent réellement via le container partagé, exactement comme en production.
• unit — le hot-path : auditEmissionHotPath est le banc le plus instructif de la brique. Il verrouille l’invariant de performance — succès authentifié et succès anonyme n’émettent rien — et couvre les quatre sorties d’échec du firewall, le câblage réel du verrou WS, l’émission des jetons et des clés, la non-fuite du secret, et l’absence d’événement fantôme.
• intégration + e2e (base réelle) : les stores Drizzle sur SQLite, plus des e2e PostgreSQL et MySQL/MariaDB gatés par NF_PG_URL / NF_MYSQL_URL — round-trip JSON, curseur composite avec collision à la milliseconde, et le compteur de purge normalisé par driver.
• banc de contrat : auditPaginationContract — une seule suite d’invariants de lecture, déroulée sur le store mémoire et sur Drizzle en trois dialectes. Un écart de comportement entre backends devient un échec de test, par construction.

Ce qui manque aujourd’hui : pas de test d’attaque dédié (*.attack.test.ts) sur le journal lui-même — les scénarios hostiles passent par les bancs d’attaque des briques voisines (autorisation, frames WS) ; et pas de banc de charge dédié à l’écriture d’audit.

❗ Important

Un skip est vert. Les e2e PostgreSQL et MySQL ne s’exécutent qu’avec leurs variables d’infra ; sans elles, la suite passe sans avoir rien prouvé sur ces dialectes. Lancer les bases par docker compose --profile postgres up -d postgres avant de conclure.

Couverture : npm run coverage dans @nodefony/security.

🔗 Pour aller plus loin#

• ⬆️ Retour au hub : Sécurité — vue d’ensemble · Toute la documentation
• Ce que le journal alimente → webhooks
• D’où viennent les événements auth.* → firewall · les login.* → authenticators
• D’où viennent les access.denied → authorization
• Les événements token.* → tokens · les apikey.* → api-keys
• Vocabulaire transverse de la sécurité → lexique