@nodefony/security 10.0.0-beta.6 → 10.0.0-beta.7

package/docs/audit.md

@@ -21,7 +21,7 @@ tags:
   ]
 version: "doc"
 status: stable
-updated: 2026-07-19
+updated: 2026-11-13
 source: "src/packages/@nodefony/security/docs/audit.md"
 ---
 
@@ -87,6 +87,7 @@ webhooks, console — se branche autour de lui.
 | Append-only       | On n'ajoute que des lignes ; rien n'est modifié ni supprimé, sauf la purge de rétention.           |
 | Rétention         | Durée pendant laquelle un événement reste consultable avant purge (`retentionDays`).               |
 | GC                | _Garbage collection_ : la purge périodique des événements hors rétention.                          |
+| Agrégation        | Un flot de refus d'une même source s'écrit en quelques lignes, puis une ligne de **synthèse**.     |
 | Curseur           | Jeton opaque « donne-moi la suite après celui-ci » — la façon de paginer un flux qui grandit.      |
 | Cold-path         | Chemin d'exception (échec, refus). Par opposition au **hot-path** : le chemin nominal, à coût nul. |
 | Fire-and-forget   | On lance l'écriture sans l'attendre : le flux métier ne dépend pas de son succès.                  |
@@ -246,7 +247,7 @@ sans qu'on l'ait demandée (IP, User-Agent, `requestId`), et les `flags` disent
 
 Le même journal est consultable dans **Studio → Sécurité → Journal d'audit**.
 
-## ⚙️ Quatre situations — du besoin à la config
+## ⚙️ Cinq situations — du besoin à la config
 
 ### Situation 1 — « Qui s'est connecté à ce compte cette nuit ? »
 
@@ -327,7 +328,70 @@ Le store mémoire porte une **seconde** protection, indépendante du temps : un
 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 »
+### Situation 4 — « Un flot de refus ne doit pas noyer la base »
+
+Un robot essaie des mots de passe à 1 000 requêtes par seconde. Une ligne par refus, c'est
+86 millions de lignes par jour, conservées toute la rétention — et l'OWASP Logging Cheat Sheet
+demande justement que la journalisation n'épuise ni les ressources ni la base.
+
+Rien à configurer : les **refus** (`failure` et `denied`) sont agrégés par défaut
+(`AuditRefusalAggregator.ts#AuditRefusalAggregator`). Pour une même **source** — même catégorie,
+action, issue, motif, ressource et **IP** — et par fenêtre de 60 secondes ouverte au premier refus :
+
+1. les **10 premiers** refus sont écrits tels quels, acteur compris : l'enquêteur voit les premiers
+   essais et les comptes visés ;
+2. les suivants sont **comptés**, ni écrits ni diffusés en direct
+   (`AuditRefusalAggregator.ts#AuditRefusalAggregator.admit`) ;
+3. la fenêtre close écrit **une** ligne de synthèse qui porte le compte.
+
+```json
+{
+  "category": "auth",
+  "action": "auth.failure",
+  "outcome": "failure",
+  "actor": null,
+  "resource": "api",
+  "reason": "invalid_credentials",
+  "ip": "203.0.113.7",
+  "metadata": {
+    "aggregated": {
+      "count": 59990,
+      "firstTs": 1763548800450,
+      "lastTs": 1763548859998,
+      "windowMs": 60000
+    }
+  }
+}
+```
+
+Trois choix à connaître :
+
+- **L'IP est celle du contexte**, résolue derrière un proxy de confiance (`trustProxy`), donc non
+  forgeable par le client (`readAuditContext.ts#readAuditContext`).
+- **L'acteur n'entre pas dans la clé.** Un bourrage d'identifiants change de compte à chaque essai :
+  c'est sa source qui le trahit. La synthèse porte `actor: null` plutôt qu'un acteur choisi au hasard.
+- **Les succès ne sont jamais agrégés** : un login réussi reste une ligne, toujours.
+
+La mémoire est bornée : au-delà de 10 000 sources suivies, les refus se regroupent sous l'IP `*`.
+Le balayage des fenêtres échues n'est armé qu'au premier refus et s'arrête quand la table est vide
+(`auditService.ts#AuditService.#startSweep`) ; à l'arrêt du serveur, les comptes en cours sont résumés
+avant que le store ne soit lâché (`auditService.ts#AuditService.#shutdown`).
+
+```typescript
+use("@nodefony/security", {
+  audit: {
+    // Plus de lignes détaillées par source, sur une fenêtre plus courte.
+    aggregate: { burst: 50, windowMs: 10_000 },
+    // Ou une ligne par refus, sans exception :
+    // aggregate: { enabled: false },
+  },
+});
+```
+
+Ce qu'on observe : pour lister les flots, filtrer sur l'issue et repérer les événements dont
+`metadata.aggregated` est présent ; leur `ip` désigne la source.
+
+### Situation 5 — « Ne rien perdre quand le store tombe »
 
 La base est indisponible pendant trente secondes. Que se passe-t-il ?
 
@@ -453,7 +517,7 @@ garantit un seul appel d'horloge, centralisé hors des points d'émission.
 | `userAgent` | `string \| null`           | contexte | provenance client                                                          |
 | `requestId` | `string \| null`           | contexte | corrélation log ↔ audit ↔ trace                                            |
 | `flags`     | `IAuditEventFlags`         | contexte | **présence** de matériel sensible, jamais la valeur                        |
-| `metadata`  | `Record<string, unknown>`  | émetteur | extras applicatifs libres, absents par défaut                              |
+| `metadata`  | `Record<string, unknown>`  | émetteur | extras applicatifs libres ; `aggregated` sur une ligne de synthèse         |
 
 Les quatre derniers champs de provenance sont remplis d'un coup par `readAuditContext()`
 (`readAuditContext.ts#readAuditContext`), qui lit un contexte HTTP ou WS de façon défensive — tous les champs sont
@@ -462,7 +526,7 @@ 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.
+Six 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
@@ -477,7 +541,17 @@ aucun appel d'horloge. Prouvé par le banc « audit désactivé → `issueTokens
 **3. L'écriture ne bloque pas.** `append()` part sans `await`, avec un `.catch()` qui logge
 (`auditService.ts#AuditService.record`). 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
+**4. Les écritures SQL sont groupées.** Le store Drizzle accumule les événements d'un tour de boucle
+et les écrit en un seul `INSERT` multi-lignes au tour suivant (`DrizzleAuditStore.ts#DrizzleAuditStore.append`) ;
+une lecture ou une purge vide d'abord le lot en attente, donc on relit toujours ce qu'on vient
+d'écrire. Mesuré sur un serveur de production local : un refus coûtait plus cher qu'un appel réussi
+quand chaque événement avait son `INSERT` ; groupé, il revient au même ordre de grandeur.
+
+**5. Un flot de refus se résume.** Au-delà de quelques refus d'une même source par fenêtre, les
+suivants sont comptés au lieu d'être écrits (voir la situation 4). Le coût d'un refus compté se
+réduit à une recherche dans une table bornée.
+
+**6. 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#AuditService.subscribe`). 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#createAuditBridge`) ; son minuteur est armé à la demande et
@@ -494,13 +568,17 @@ jamais faire tomber ce qu'on supervise.
 Table dérivée du schéma Zod `auditSchema` (`config.ts#auditSchema`), rattaché à la racine sous la clé `audit`
 (`config.ts#securityConfigSchema`).
 
-| Option          | Type      | Défaut   | Effet                                                                                |
-| --------------- | --------- | -------- | ------------------------------------------------------------------------------------ |
-| `enabled`       | `boolean` | `true`   | `false` → `record()` no-op à coût nul, `listPage()` page vide, endpoint admin en 503 |
-| `store`         | `string`  | `"auto"` | nom résolu par le registre : `auto`, `memory`, `drizzle`, `mongoose`                 |
-| `retentionDays` | `number`  | `365`    | fenêtre de conservation ; au-delà, la purge horaire supprime                         |
-| `immutable`     | `boolean` | `true`   | déclaré au schéma — voir l'avertissement ci-dessous                                  |
-| `stream`        | `boolean` | `true`   | déclaré au schéma — voir l'avertissement ci-dessous                                  |
+| Option               | Type      | Défaut   | Effet                                                                                |
+| -------------------- | --------- | -------- | ------------------------------------------------------------------------------------ |
+| `enabled`            | `boolean` | `true`   | `false` → `record()` no-op à coût nul, `listPage()` page vide, endpoint admin en 503 |
+| `store`              | `string`  | `"auto"` | nom résolu par le registre : `auto`, `memory`, `drizzle`, `mongoose`                 |
+| `retentionDays`      | `number`  | `365`    | fenêtre de conservation ; au-delà, la purge horaire supprime                         |
+| `immutable`          | `boolean` | `true`   | déclaré au schéma — voir l'avertissement ci-dessous                                  |
+| `stream`             | `boolean` | `true`   | déclaré au schéma — voir l'avertissement ci-dessous                                  |
+| `aggregate.enabled`  | `boolean` | `true`   | agrège les refus d'une même source ; `false` → une ligne par refus                   |
+| `aggregate.windowMs` | `number`  | `60000`  | durée d'une fenêtre, ouverte au premier refus d'une source                           |
+| `aggregate.burst`    | `number`  | `10`     | refus écrits tels quels par source et par fenêtre, avant le simple comptage          |
+| `aggregate.maxKeys`  | `number`  | `10000`  | sources suivies au plus ; au-delà, regroupement sous l'IP `*`                        |
 
 > [!WARNING]
 > `immutable` et `stream` sont déclarés dans le schéma mais **ne sont lus par aucun code** aujourd'hui.
@@ -626,8 +704,9 @@ filtrage, jamais de sémantique.
 L'entité et la fabrique sont enregistrées automatiquement par l'adapter au démarrage
 (`registerStores.ts#registerMongooseFrameworkStores`, entité via `registerAuditEntities()`, `auditEventEntity.ts#registerAuditEntities`). Côté
 implémentation, `DrizzleAuditStore` (`DrizzleAuditStore.ts#DrizzleAuditStore`) 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.
+appel**, pas à la construction : l'ordre de démarrage n'est pas garanti. À l'arrêt, l'audit vide son
+agrégateur à `onTerminate`, après le drain des serveurs et avant la déconnexion de l'ORM : sa
+libération s'inscrit à la résolution du store, donc après celle du connecteur (ADR-0027).
 
 ## 🔐 Sécurité — ce qui n'entre JAMAIS dans le journal
 
@@ -667,6 +746,7 @@ Deux autres propriétés de sécurité valent d'être connues :
 | ----------------------------------------- | --------------------------------- | -------------------------------------------------------------------------------------------- |
 | Journaliser les échecs d'authentification | OWASP Logging Cheat Sheet         | `auth.failure`/`auth.throttled`/`auth.denied` (`firewall.ts#Firewall.describeRoleHierarchy`) |
 | Journaliser les refus d'autorisation      | OWASP A09:2021                    | `access.denied` sur tout refus du jury (`authorization.ts#Authorization.#auditDeny`)         |
+| Ne pas épuiser les ressources ni la base  | OWASP Logging Cheat Sheet         | refus agrégés par source et par fenêtre (`AuditRefusalAggregator.ts#AuditRefusalAggregator`) |
 | Ne jamais journaliser de secret           | OWASP Logging Cheat Sheet         | flags de **présence** seuls (`IAuditEvent.ts#AuditOutcome`)                                  |
 | Traçabilité « qui, quoi, quand, d'où »    | ISO 27001 A.8.15 (journalisation) | acteur, action, horodatage et provenance dans `IAuditEvent` (`IAuditEvent.ts#IAuditEvent`)   |
 | Journal inaltérable                       | ISO 27001 A.8.15                  | contrat append-only, aucune mutation exposée (`IAuditStore.ts#IAuditStore`)                  |
@@ -699,19 +779,20 @@ webhook. Détail des souscriptions, de la signature et des relivraisons → [web
 
 ## ⚠️ Pièges
 
-| Symptôme                                            | Cause (dans le code)                                                                   | Correction                                                 |
-| --------------------------------------------------- | -------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
-| Journal vide après un redémarrage                   | Store `memory` : volatile et per-pod (`MemoryAuditStore.ts#MemoryAuditStore`)          | `audit.store: "drizzle"` (ou déclarer `NF_DATABASE_URL`)   |
-| Un pod voit des événements, l'autre non             | Store `memory` non partagé                                                             | Store durable partagé                                      |
-| Le boot échoue en production sur l'audit            | Store **explicite** inconnu, fail-closed (`auditService.ts#AuditService.#build`)       | Corriger le nom, ou charger l'adapter qui l'enregistre     |
-| `limit=5000` ne rend que 200 événements             | Plafond de l'endpoint (`parsePageQuery`, `pageQuery.ts#toPageParams`)                  | Paginer avec `nextCursor`, jamais gonfler `limit`          |
-| La page 2 répète ou saute des événements            | Pagination réimplémentée en offset                                                     | Repasser le `nextCursor` reçu — le curseur est opaque      |
-| `?category=authen` renvoie 400                      | Valeur hors union refusée (`PageQueryError`)                                           | Utiliser une valeur de l'union (`auth`, `authz`, `token`…) |
-| Le paramètre `q` renvoie 400                        | Recherche plein texte non supportée sur ce journal                                     | Filtrer par `category`/`actor`/`action`/`requestId`        |
-| `stream: false` ne coupe pas le live                | Drapeau non lu ; le live suit `#listeners` (`auditService.ts#AuditService.#listeners`) | Retirer le rôle admin, ou ne pas exposer le canal          |
-| Trous dans le journal pendant une panne de base     | Écriture best-effort (`auditService.ts#AuditService.record`)                           | Store à haute disponibilité si la conformité l'exige       |
-| Aucun `login.success` alors que les logins marchent | Le succès du **firewall** est muet ; `login.success` vient du BFF                      | Filtrer `action=login.success`, pas `category=auth` seul   |
-| Endpoint d'audit en 503                             | `audit.enabled: false` (`SecurityAdminApi.ts#createSecurityAdminApi`)                  | Réactiver l'audit en configuration                         |
+| Symptôme                                            | Cause (dans le code)                                                                   | Correction                                                      |
+| --------------------------------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
+| Journal vide après un redémarrage                   | Store `memory` : volatile et per-pod (`MemoryAuditStore.ts#MemoryAuditStore`)          | `audit.store: "drizzle"` (ou déclarer `NF_DATABASE_URL`)        |
+| Un pod voit des événements, l'autre non             | Store `memory` non partagé                                                             | Store durable partagé                                           |
+| Le boot échoue en production sur l'audit            | Store **explicite** inconnu, fail-closed (`auditService.ts#AuditService.#build`)       | Corriger le nom, ou charger l'adapter qui l'enregistre          |
+| `limit=5000` ne rend que 200 événements             | Plafond de l'endpoint (`parsePageQuery`, `pageQuery.ts#toPageParams`)                  | Paginer avec `nextCursor`, jamais gonfler `limit`               |
+| La page 2 répète ou saute des événements            | Pagination réimplémentée en offset                                                     | Repasser le `nextCursor` reçu — le curseur est opaque           |
+| `?category=authen` renvoie 400                      | Valeur hors union refusée (`PageQueryError`)                                           | Utiliser une valeur de l'union (`auth`, `authz`, `token`…)      |
+| Le paramètre `q` renvoie 400                        | Recherche plein texte non supportée sur ce journal                                     | Filtrer par `category`/`actor`/`action`/`requestId`             |
+| `stream: false` ne coupe pas le live                | Drapeau non lu ; le live suit `#listeners` (`auditService.ts#AuditService.#listeners`) | Retirer le rôle admin, ou ne pas exposer le canal               |
+| Trous dans le journal pendant une panne de base     | Écriture best-effort (`auditService.ts#AuditService.record`)                           | Store à haute disponibilité si la conformité l'exige            |
+| Aucun `login.success` alors que les logins marchent | Le succès du **firewall** est muet ; `login.success` vient du BFF                      | Filtrer `action=login.success`, pas `category=auth` seul        |
+| 10 lignes pour 1 000 échecs d'une même IP           | Agrégation des refus (`AuditRefusalAggregator.ts#AuditRefusalAggregator`)              | Lire la synthèse (`metadata.aggregated`), ou régler `aggregate` |
+| Endpoint d'audit en 503                             | `audit.enabled: false` (`SecurityAdminApi.ts#createSecurityAdminApi`)                  | Réactiver l'audit en configuration                              |
 
 ## 🧪 Tests & couverture
 
@@ -723,6 +804,9 @@ Cinq familles couvrent la brique :
   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'agrégation** : `auditRefusalAggregator` prouve qu'un flot d'une source s'écrit en
+  10 lignes plus une synthèse, que deux IP restent deux sources, que la mémoire est bornée, que
+  l'arrêt résume les comptes en cours et que les succès ne sont jamais agrégés.
 - **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

package/docs/keycloak.md

@@ -265,10 +265,10 @@ lui, en a un de test — Mailpit (`--profile keycloak`, interface `http://localh
    processus dès le démarrage, commandes en ligne comprises (`addDefaultCaCertificate()`,
    `certificates.ts#addDefaultCaCertificate`). La variable `NODE_EXTRA_CA_CERTS` n'est plus nécessaire.
 
-Le realm généré porte aussi, comme celui du dépôt, un client **machine** `<app>-machine` (compte de
-service, `client_credentials`). Ses jetons portent l'audience de la zone `partner` que le gabarit
-`complete` ouvre (`https://localhost:5152/api/partner`) : `npx nodefony app:partner:call --issuer
-keycloak` obtient un jeton et appelle `GET /api/partner/whoami` dès le premier démarrage. Quand tu
+Une application créée avec `--demo` reçoit aussi, comme le dépôt, un client **machine** `<app>-machine`
+(compte de service, `client_credentials`). Ses jetons portent l'audience de la zone `demo-partner`
+que la démo ouvre (`https://localhost:5152/demo/api/partner`) : `npx nodefony demo:partner:call
+--issuer keycloak` obtient un jeton et appelle `GET /demo/api/partner/whoami` dès le premier démarrage. Quand tu
 ouvres une autre zone (section « Le jeton Keycloak sur ton API », plus bas),
 `npx nodefony security:keycloak:realm --write` ajoute le mapper qui inscrit sa `resource` dans les
 jetons.

package/docs/obtenir-un-jeton.md

@@ -125,15 +125,15 @@ Puis `npm run build` — le runtime lit le `dist`, pas la source.
 
 ### Les options, et ce que chacune décide
 
-| Option                 | Défaut                                       | Ce qu'elle change                                        |
-| ---------------------- | -------------------------------------------- | -------------------------------------------------------- |
-| `[identifier]`         | `admin`                                      | le compte porteur du jeton                               |
-| `-s, --scope <liste>`  | `admin:read`                                 | les pouvoirs demandés — ajouter `admin:write` pour muter |
-| `-r, --resource <uri>` | la porte MCP de l'application                | viser une **autre** audience                             |
-| `-a, --agent <noms>`   | ceux détectés                                | quels agents servir — `none` pour aucun                  |
-| `-t, --ttl <minutes>`  | 8 h avec `--write`, sinon la config (15 min) | la durée de validité, **bornée à 30 jours**              |
-| `-w, --write`          | proposé en terminal                          | poser `NF_MCP_TOKEN` chez les agents présents            |
-| `-j, --json`           | —                                            | sortie machine, sans invite                              |
+| Option                 | Défaut                                       | Ce qu'elle change                                                                                        |
+| ---------------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
+| `[identifier]`         | `admin`                                      | le compte porteur du jeton                                                                               |
+| `-s, --scope <liste>`  | `admin:read`                                 | les pouvoirs demandés — ajouter `admin:write` pour muter                                                 |
+| `-r, --resource <uri>` | la porte MCP de l'application                | viser une **autre** porte — son jeton va dans l'en-tête de l'agent, jamais dans `NF_MCP_TOKEN`           |
+| `-a, --agent <noms>`   | ceux détectés                                | quels agents servir — `none` pour aucun                                                                  |
+| `-t, --ttl <minutes>`  | 8 h avec `--write`, sinon la config (15 min) | la durée de validité, **bornée à 30 jours**                                                              |
+| `-w, --write`          | proposé en terminal                          | poser `NF_MCP_TOKEN` chez les agents présents — **refusé** avec un `--resource` qui vise une autre porte |
+| `-j, --json`           | —                                            | sortie machine, sans invite                                                                              |
 
 Le plafond de `--ttl` n'est pas décoratif : un jeton posé dans un fichier **est une clé**, et une
 clé se remplace (`security-mcp-token.ts#ttlSeconds`).
@@ -152,6 +152,13 @@ les agents dont la présence est **constatée** dans le projet — on ne crée p
 outil que personne n'utilise ici. La table des cibles vit au cœur
 (`src/nodefony/src/cli/agentTargets.ts#AGENT_TARGETS`) : Claude, Gemini, Vibe, Codex.
 
+`NF_MCP_TOKEN` sert **la porte de l'outillage**, et elle seule. Un jeton émis pour une autre porte
+(`--resource`) porte une autre audience : posé dans cette variable, il serait refusé par la porte de
+l'outillage, dont les outils réservés disparaîtraient sans un mot. La commande refuse donc `--write`
+dans ce cas, et n'affiche pas de ligne d'`export` (`security-mcp-token.ts#targetsOtherGate`) : ce
+jeton va dans l'en-tête de l'agent qui parle à cette porte, par exemple
+`claude mcp add --transport http <nom> <porte> --header "Authorization: Bearer <le jeton>"`.
+
 Deux garanties qui ne se négocient pas :
 
 - **jamais dans un fichier suivi par git** — un jeton commité est un jeton publié, et c'est la seule
@@ -246,7 +253,7 @@ audiences: ctx.isProd
   ? []
   : [
       // … les audiences du gabarit
-      `${publicBaseUrl(ctx.env)}/api/mcp`,
+      `${publicBaseUrl(ctx.env)}/mcp`,
     ],
 ```
 

package/docs/tokens.md

@@ -485,7 +485,7 @@ Tables dérivées du schéma Zod — `jwtSchema` (`config.ts#jwtSchema`) et `tok
 | `refreshTtlS` | number (s) | `604800` | TTL du refresh — 7 jours (`config.ts#jwtSchema`) |
 | `rotateRefresh` | boolean | `true` | Rotation du refresh à chaque usage, OWASP (`config.ts#jwtSchema`) |
 | `jwks` | boolean | `true` | Publie `/.well-known/jwks.json` + les métadonnées RFC 8414 — sans `issuer` en URL https, rien n'est publié |
-| `audiences` | string[] | `[]` | `aud` acceptées (RFC 8707) ; vide = `[issuer]` (`config.ts#jwtSchema`) |
+| `audiences` | string[] | `[]` | Liste blanche des `aud` ÉMETTABLES (RFC 8707), la 1ʳᵉ = défaut ; vide = `[issuer]`. Une zone `jwt` n’accepte que SA `resource`, sinon l’audience par défaut (`JwtAuthenticator.ts#JwtAuthenticator.authenticate`) |
 | `issuer` | string? | — | Claim `iss`, **STABLE** après émission ; omis → repli `"nodefony"`, qui n'est PAS publiable (RFC 8414 §2 exige une URL https) |
 | `keystore.keySetJson` | string? | — | JWK Set privé partagé par tous les process (`NF_JWT_KEYSET`) — SECRET, forme vérifiée au démarrage (`security/nodefony/config/config.ts#jwtSchema`) |
 | `keystore.dir` | string? | — | Dossier `keyset.json` chmod 600, création exclusive — dev, ou serveur unique à disque persistant (`config.ts#jwtSchema`) |

package/docs/webhooks.md

@@ -582,22 +582,30 @@ appliqué **deux fois** : à l'enregistrement, et **à nouveau juste avant chaqu
 | IPv4-mapped IPv6 sous toutes ses notations          | `::ffff:7f00:1`, `0:0:0:0:0:ffff:127.0.0.1` | rabattu nativement sur les règles IPv4 par `BlockList` (`isBlockedAddress()`, `ssrfGuard.ts#isBlockedAddress`) |
 | IP encodée en dword/hex/octal dans le nom d'hôte    | `http://2130706433/`                        | on passe l'IP **résolue** à `isBlockedAddress()`, jamais la chaîne d'hôte (`ssrfGuard.ts#isBlockedAddress`)    |
 | Nom DNS public qui **résout** vers du privé         | `hook.evil.com → 10.0.0.5`                  | toutes les IP résolues sont contrôlées, une seule interne = refus                                              |
-| **DNS rebinding** entre le contrôle et la connexion | —                                           | l'IP validée est **pinnée** à la connexion TCP (`webhookDelivery.ts#deliverWebhook`)                           |
-| **Redirection** `302 → 169.254.169.254`             | —                                           | `node:http(s)` ne suit **jamais** les 3xx ; le 3xx est rendu tel quel                                          |
+| **DNS rebinding** entre le contrôle et la connexion | —                                           | l'IP validée est **pinnée** à la connexion TCP (`fetchPublic.ts#fetchPublic`)                                  |
+| **Redirection** `302 → 169.254.169.254`             | —                                           | la livraison ne suit **aucune** redirection (`maxRedirects` à 0) ; le 3xx est rendu tel quel                   |
+| **Goutte-à-goutte** : un octet toutes les 3 s       | —                                           | délai **total** de la livraison, pas seulement d'inactivité (`fetchPublic.ts#IFetchPublicOptions.timeoutMs`)   |
+| **Corps de réponse infini**                         | —                                           | lecture coupée à 2 Kio et connexion détruite (`fetchPublic.ts#IFetchPublicOptions.maxBytes`)                   |
 
 ### Les deux subtilités qui font la différence
 
 **Le pin d'IP.** Valider puis se reconnecter, c'est laisser une fenêtre : le DNS peut répondre une IP
 publique au contrôle et une IP privée 50 ms plus tard. `deliverWebhook()` (`webhookDelivery.ts#deliverWebhook`)
-installe un `lookup` qui force la connexion vers l'IP **déjà validée**, tout en conservant le nom
+appelle `fetchPublic()` (`fetchPublic.ts#fetchPublic`), qui installe un `lookup` qui force la connexion vers l'IP **déjà validée**, tout en conservant le nom
 d'hôte pour le SNI/TLS et l'en-tête `Host`. Le second contrôle SSRF avant livraison —
 `resolveTarget()` (`WebhookDispatcher.ts#IWebhookDispatcherDeps.resolveTarget`) — sert exactement à produire ces adresses ; s'il échoue, la livraison est
 **abandonnée sans retry** (une cible devenue interne ne redeviendra pas légitime au réessai).
 
 **Le non-suivi des redirections.** `fetch()` suit les 3xx par défaut — ce qui annulerait tout le
-travail précédent. Le choix de `node:http(s)` natif n'est donc pas seulement une économie de
-dépendance : c'est une **propriété de sécurité**, couverte par un test dédié
-(`webhookDelivery.test.ts`, « 302 vers 169.254.169.254 → rendu tel quel, JAMAIS suivi »).
+travail précédent. `fetchPublic()` n'en suit aucune tant que `maxRedirects` reste à 0 (la livraison ne le change
+jamais), et quand un appelant en autorise, chaque cible est revérifiée comme la première. Couvert par
+`webhookDelivery.test.ts` (« 302 vers 169.254.169.254 → rendu tel quel, JAMAIS suivi ») et
+`fetchPublic.attack.test.ts`.
+
+**La même brique pour tout appel sortant.** `fetchPublic()` est exportée : tout code qui lit une adresse venue d'un
+humain (aperçu de lien, agent, RAG) l'appelle au lieu de `fetch()` — IP vérifiée puis épinglée à chaque saut,
+délai total, corps borné et non décodé. Refus de cible : `SsrfError` (422) ; site muet ou trop lent :
+`FetchPublicError` (`reason`).
 
 > [!CAUTION]
 > `assertPublicUrl()` fait un `Fail-closed` sur l'inconnu : une adresse syntaxiquement invalide est
@@ -1016,7 +1024,7 @@ secret, et sait **simuler des pannes** pour observer retries et auto-désactivat
 | Le récepteur voit deux fois le même événement                                  | Un retry rejoue le **même** `webhook-id`                                                                                             | Dédupliquer par `webhook-id` côté récepteur                            |
 | Endpoint passé `enabled: false` tout seul                                      | 20 échecs consécutifs → auto-désactivation (`webhooks.ts#WebhookService.rotateSecret`)                                               | Réparer la destination, puis `PATCH … {"enabled":true}`                |
 | Livraisons « abandonnées » dans les logs                                       | File pleine (`maxQueue`) — best-effort assumé                                                                                        | Augmenter `maxQueue`/`maxConcurrent`, ou réduire le volume souscrit    |
-| Un `302` vers l'interne n'est pas suivi                                        | **Voulu** : `node:http(s)` ne suit jamais les 3xx                                                                                    | Rien à corriger — configurer l'URL finale côté destinataire            |
+| Un `302` vers l'interne n'est pas suivi                                        | **Voulu** : la livraison ne suit aucune redirection                                                                                  | Rien à corriger — configurer l'URL finale côté destinataire            |
 | Le secret a été perdu                                                          | Il n'est montré qu'à la création/rotation                                                                                            | `POST …/reveal` (audité) ou rotation + redéploiement chez le tiers     |
 | Après un redémarrage, plus aucun endpoint                                      | `store: "memory"` — registre volatil et par pod                                                                                      | Déclarer une infra durable (`store: "auto"` suffit alors)              |
 | Multi-pod : un endpoint créé ne livre pas tout de suite depuis les autres pods | Le snapshot est relu après `webhooks.snapshotTtlS` (30 s par défaut, `webhooks.ts#WebhookService.#touchSnapshot`), pas immédiatement | Attendre au plus `snapshotTtlS`, ou le baisser                         |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nodefony/security",
-  "version": "10.0.0-beta.6",
+  "version": "10.0.0-beta.7",
   "description": "Pare-feu applicatif par zones pour Nodefony : authentification, autorisation par rôles, protection CSRF, journal d'audit",
   "author": "Christophe CAMENSULI <ccamensuli@gmail.com>",
   "main": "./dist/index.js",
@@ -35,7 +35,7 @@
   },
   "private": false,
   "engines": {
-    "node": ">=24.14.0"
+    "node": "^24.16.0 || >=26.0.0"
   },
   "keywords": [
     "nodefony",
@@ -55,28 +55,28 @@
     "directory": "src/packages/@nodefony/security"
   },
   "dependencies": {
-    "@simplewebauthn/server": "14.0.3",
-    "jose": "6.2.15",
+    "@simplewebauthn/server": "14.1.0",
+    "jose": "6.2.17",
     "tslib": "2.9.1",
     "zod": "^4.6.7"
   },
   "devDependencies": {
-    "@nodefony/framework": "^10.0.0-beta.6",
-    "@nodefony/http": "^10.0.0-beta.6",
-    "@nodefony/user": "^10.0.0-beta.6",
+    "@nodefony/framework": "^10.0.0-beta.7",
+    "@nodefony/http": "^10.0.0-beta.7",
+    "@nodefony/user": "^10.0.0-beta.7",
     "@types/node": "26.6.6",
     "@vitest/coverage-v8": "5.1.0",
-    "nodefony": "^10.0.0-beta.6",
+    "nodefony": "^10.0.0-beta.7",
     "vitest": "5.1.0"
   },
   "license": "Apache-2.0",
   "readmeFilename": "README.md",
   "contributors": [],
   "peerDependencies": {
-    "@nodefony/framework": "^10.0.0-beta.6",
-    "@nodefony/http": "^10.0.0-beta.6",
-    "@nodefony/user": "^10.0.0-beta.6",
-    "nodefony": "^10.0.0-beta.6"
+    "@nodefony/framework": "^10.0.0-beta.7",
+    "@nodefony/http": "^10.0.0-beta.7",
+    "@nodefony/user": "^10.0.0-beta.7",
+    "nodefony": "^10.0.0-beta.7"
   },
   "files": [
     "dist",
@@ -86,7 +86,7 @@
   "publishConfig": {
     "access": "public"
   },
-  "homepage": "https://nodefony.github.io/nodefony-core/",
+  "homepage": "https://nodefony.net/",
   "bugs": {
     "url": "https://github.com/nodefony/nodefony-core/issues"
   }