@nodefony/security 10.0.0-alpha.9 → 10.0.0-beta.2

package/docs/webauthn.md

@@ -54,7 +54,7 @@ flowchart LR
 Le défi vit **hors du service**, en session BFF, posé par le controller
 (`WebAuthnController.registerOptions()`, `WebAuthnController.ts:113`). Chaque `verify*` reçoit
 l'`expectedChallenge` qu'il a émis, et le controller **l'invalide dès sa lecture**
-(`WebAuthnController.#takeChallenge()`, `WebAuthnController.ts:277`) : un défi ne sert qu'une fois.
+(`WebAuthnController.#takeChallenge()`, `WebAuthnController.ts:281`) : un défi ne sert qu'une fois.
 
 ## 📖 Lexique
 
@@ -90,7 +90,7 @@ Quatre failles fermées **par construction** :
 2. **Fuite de base** — le serveur ne stocke que des clés **publiques** (`IWebAuthnCredential.publicKey`,
    `IWebAuthnCredential.ts:16`). Une base volée ne donne aucun accès.
 3. **Rejeu** — le défi est à usage unique, invalidé en session dès sa lecture
-   (`WebAuthnController.#takeChallenge()`, `WebAuthnController.ts:277`).
+   (`WebAuthnController.#takeChallenge()`, `WebAuthnController.ts:281`).
 4. **Clonage d'authenticator** — le `signCount` doit croître ; une régression signale une copie
    (`IWebAuthnCredential.signCount`, `IWebAuthnCredential.ts:22`).
 
@@ -114,7 +114,7 @@ Trois partis pris assumés :
 - **Le stockage est pluggable** (`IWebAuthnCredentialStore`, `IWebAuthnCredentialStore.ts:75`) :
   mémoire par défaut, ORM ou Redis en production, avec le **même banc de contrat** pour tous.
 - **Les endpoints sont fournis**, pas à réécrire (`mountWebAuthnRoutes()`,
-  `WebAuthnController.ts:308`) : c'est là que vivent les gardes délicates (session du défi, usage
+  `WebAuthnController.ts:314`) : c'est là que vivent les gardes délicates (session du défi, usage
   unique, messages uniformes, anti-IDOR).
 
 ## 🚀 Démarrage rapide
@@ -155,7 +155,7 @@ export default defineConfig(() => ({
 ### 2. Les endpoints BFF sont FOURNIS
 
 Dès que `@nodefony/security` est chargé, le framework monte six routes
-(`mountWebAuthnRoutes()`, `WebAuthnController.ts:308`) :
+(`mountWebAuthnRoutes()`, `WebAuthnController.ts:314`) :
 
 | Route (`POST` sauf mention)                        | Rôle                                          | Firewall                  |
 | -------------------------------------------------- | --------------------------------------------- | ------------------------- |
@@ -170,7 +170,7 @@ Dès que `@nodefony/security` est chargé, le framework monte six routes
 > Les quatre routes de cérémonie sont `bypassFirewall: true` (`WebAuthnController.ts:365`) : elles
 > **sont** le mécanisme d'authentification — les protéger exigerait d'être déjà connecté pour se
 > connecter. Le contrôle d'accès de `register/*` est fait **dans le controller**
-> (`flow.me()` → 401, `WebAuthnController.ts:106`). Les deux routes self-service, elles, restent dans
+> (`flow.me()` → 401, `WebAuthnController.ts:119`). Les deux routes self-service, elles, restent dans
 > la zone protégée (`security.webauthn.credentials.list`, `WebAuthnController.ts:314`).
 
 ### 3. Ce que TU écris : l'appel navigateur
@@ -217,7 +217,7 @@ export async function enrollPasskey(): Promise<string> {
   return out.credentialId;
 }
 
-/** Se connecter sans mot de passe. `username` omis = passkey découvrable. */
+/** Se connecter sans mot de passe : un anonyme reçoit toujours un défi découvrable. */
 export async function loginWithPasskey(
   username?: string,
 ): Promise<{ username: string }> {
@@ -340,7 +340,7 @@ controller ouvre alors la session BFF avec `authFlow.establishSessionFor()`
 Deux chemins, deux portées :
 
 - **Self-service** : `DELETE …/webauthn/credentials/{id}` → `WebAuthnService.removeUserCredential()`
-  (`webAuthn.ts:507`). La suppression n'aboutit que si le credential **appartient** au demandeur
+  (`webAuthn.ts:502`). La suppression n'aboutit que si le credential **appartient** au demandeur
   (`webAuthn.ts:513`) ; sinon **404 indiscernable** (`WebAuthnController.ts:207`) — on ne révèle
   jamais l'existence de la passkey d'autrui.
 - **Reset administrateur** : `DELETE /nodefony/security/api/users/{id}/passkeys/{credentialId}`
@@ -361,7 +361,7 @@ Table dérivée du schéma Zod `passkeysSchema` (`config.ts:461`), monté sous l
 | `enabled`                 | boolean                                    | `true`       | Active les cérémonies ; `false` → endpoints en 503 (`config.ts:463`)           |
 | `rpId`                    | string?                                    | domaine app  | Domaine de liaison des passkeys ; IP → `localhost` (`config.ts:469`)           |
 | `rpName`                  | string?                                    | `"Nodefony"` | Nom affiché dans l'invite OS/navigateur (`config.ts:473`)                      |
-| `origins`                 | string[]                                   | `[]`         | Liste blanche d'origines ; vide = déduction depuis `rpId` (`config.ts:479`)    |
+| `origins`                 | string[]                                   | `[]`         | Liste blanche d'origines ; vide = déduction depuis `rpId` (`config.ts:469`)    |
 | `userVerification`        | `required` \| `preferred` \| `discouraged` | `preferred`  | Exiger biométrie/PIN — `required` = AAL2 (`config.ts:483`)                     |
 | `residentKey`             | `required` \| `preferred` \| `discouraged` | `preferred`  | Passkey découvrable → login sans identifiant (`config.ts:489`)                 |
 | `authenticatorAttachment` | `platform` \| `cross-platform` \| `any`    | `platform`   | Biométrie intégrée / clé externe / les deux (`config.ts:495`)                  |
@@ -404,15 +404,16 @@ sans champ à remplir.
 passkeys: { residentKey: "required" }, // la passkey DOIT être découvrable
 ```
 
-Et côté client, **n'envoie pas** `username` à `login/options` : `allowCredentials` est alors omis et
-le navigateur propose les comptes qu'il connaît. C'est aussi la variante la plus sobre côté vie
-privée — voir la section suivante.
+Côté client, rien à faire de plus : le serveur **ignore** tout `username` posté par un anonyme.
+`allowCredentials` est omis et le navigateur propose les comptes qu'il connaît. Le ciblage ne vient
+jamais du corps de la requête, seulement de la session (`WebAuthnController.loginOptions()`,
+`WebAuthnController.ts:171`).
 
-| Ce que le client envoie à `login/options` | Ce que renvoie le serveur                       | Conséquence                                      |
-| ----------------------------------------- | ----------------------------------------------- | ------------------------------------------------ |
-| `{}`                                      | défi seul, **sans** `allowCredentials`          | l'authenticator propose ses comptes              |
-| `{"username":"alice"}` (alice a 3 clés)   | défi + `allowCredentials` de **3** identifiants | ciblage — mais l'anonyme apprend qu'ils existent |
-| `{"username":"fantome"}`                  | défi + `allowCredentials: []` (200, jamais 404) | pas d'erreur révélatrice — mais liste vide       |
+| Qui appelle `login/options`             | Ce que renvoie le serveur                            | Conséquence                                 |
+| --------------------------------------- | ---------------------------------------------------- | ------------------------------------------- |
+| anonyme, `{}`                           | défi seul, **sans** `allowCredentials`               | l'authenticator propose ses comptes         |
+| anonyme, `{"username":"alice"}`         | identique : le `username` est ignoré                 | aucun ciblage, rien à apprendre sur `alice` |
+| session authentifiée (ré-auth, step-up) | défi + `allowCredentials` des clés **de ce porteur** | ciblage de ses propres passkeys             |
 
 ## 🛡️ `rpId` et origines — l'ancre anti-phishing
 
@@ -439,14 +440,16 @@ est ignoré, sans jamais ouvrir à un domaine tiers) ; en dernier recours `https
 
 ## 🔐 Le point à ne pas rater — plafond d'enrôlement et `login/options` ouvert
 
-`login/options` est **accessible à un anonyme** (`bypassFirewall`) et accepte un `username`
-(`WebAuthnController.ts:168`). C'est nécessaire — on ne peut pas exiger d'être connecté pour se
-connecter — mais cela ouvre deux surfaces qu'il faut regarder en face.
+`login/options` est **accessible à un anonyme** (`bypassFirewall`). C'est nécessaire — on ne peut
+pas exiger d'être connecté pour se connecter. Le ciblage, lui, ne vient jamais du corps : un anonyme
+reçoit toujours un défi découvrable, et seule une session authentifiée cible ses propres passkeys
+(`WebAuthnController.loginOptions()`, `WebAuthnController.ts:171`). Deux surfaces restent à
+regarder en face.
 
 ### Amplification : bornée par le plafond, pas par une pagination
 
-Avec un `username`, le serveur charge **toutes** les passkeys du porteur pour construire
-`allowCredentials` (`webAuthn.ts:399`). Cet appel `findByUser` est **volontairement non paginé** —
+Pour une session authentifiée, le serveur charge **toutes** les passkeys du porteur pour construire
+`allowCredentials` (`WebAuthnService.generateAuthenticationOptions()`, `webAuthn.ts:389`). Cet appel `findByUser` est **volontairement non paginé** —
 `allowCredentials` doit être complet ou il est faux : un authenticator absent de la liste ne peut pas
 répondre, et le protocole n'offre aucune « page suivante » (`IWebAuthnCredentialStore.ts:88`).
 
@@ -460,22 +463,17 @@ Ce qui borne donc cette lecture, c'est **`passkeys.maxPerUser`** (défaut 20, `c
   (3 comptages, 0 chargement) ;
 - retirer un appareil **libère une place** : le plafond est une borne, pas un compteur qui dérive.
 
-### Énumération : le statut est uniforme, la liste ne l'est pas
+### Énumération : rien ne distingue deux comptes
 
-Un compte inexistant reçoit **200 + un défi**, exactement comme un compte réel — le test d'attaque E3
-(`webauthn-attack.test.ts`) verrouille ce point. Aucun 404, aucun message différencié, aucune latence
-de recherche de mot de passe.
+Un anonyme reçoit **toujours le même défi découvrable**, sans `allowCredentials`, qu'il poste ou non
+un `username` : aucun statut, aucune liste, aucune latence ne dit si un compte existe ou porte une
+passkey, et l'appel ne touche même pas le store. C'est le remède que la spécification W3C WebAuthn
+propose contre la fuite des identifiants de credentials ; `webauthnLoginOptionsPrivacy.test.ts` le
+verrouille.
 
-Mais `allowCredentials` reflète la réalité : **vide** pour un identifiant sans passkey, **peuplé** (et
-portant les identifiants de credentials) pour un porteur enrôlé. Un anonyme peut donc distinguer
-« cet identifiant a au moins une passkey » de « il n'en a pas ».
-
-> [!WARNING]
-> C'est le comportement standard d'un `login/options` avec identifiant, et la parade est
-> architecturale : **ne transmets pas `username`**. Avec `residentKey: "required"` et un client qui
-> poste `{}`, `allowCredentials` est omis, aucun état de compte ne transparaît, et l'appel ne touche
-> même pas le store. Si ton UX exige la saisie d'un identifiant, place un rate-limit devant
-> `login/options` — le firewall ne le protège pas, c'est une route en `bypassFirewall`.
+> [!NOTE]
+> `login/options` reste une route en `bypassFirewall` : le firewall ne la protège pas. Un rate-limit
+> en amont reste de bonne hygiène, pour borner le coût des défis émis.
 
 Les autres gardes de cette surface, toutes couvertes par des tests d'attaque :
 
@@ -551,7 +549,7 @@ Studio (`webAuthn.ts:195`). Deux garde-fous de production :
 - `listPage` trie `createdAt` DESC avec `id` en départage → offset déterministe, parité SQL
   (`MemoryWebAuthnCredentialStore.ts:26`). C'est lui qui pilote le banc de contrat partagé.
 - `snapshot()` / `restore()` sérialisables (`MemoryWebAuthnCredentialStore.ts:181`) ; le service
-  déclenche un `flushNow()` à l'arrêt si le store sait le faire (`webAuthn.ts:257`).
+  déclenche un `flushNow()` à l'arrêt si le store sait le faire (`webAuthn.ts:47`).
 
 ### `drizzle` — SQL, le durable par défaut
 
@@ -611,8 +609,8 @@ symbolique (`.ai/symbols.json`).
 | `listUserCredentials()`           | « Mes appareils » — chemin chaud, non paginé (`webAuthn.ts:466`)         |
 | `listCredentialsPage()`           | Vue **transverse** admin, paginée, sans clé publique (`webAuthn.ts:479`) |
 | `countCredentials()`              | Total filtré, ou `-1` si le backend ne compte pas (`webAuthn.ts:490`)    |
-| `removeUserCredential()`          | Révocation self-service, owner-scopée (`webAuthn.ts:507`)                |
-| `removeCredential()`              | Révocation inconditionnelle, usage admin (`webAuthn.ts:496`)             |
+| `removeUserCredential()`          | Révocation self-service, owner-scopée (`webAuthn.ts:502`)                |
+| `removeCredential()`              | Révocation inconditionnelle, usage admin (`webAuthn.ts:492`)             |
 
 Types publics ré-exportés par `@nodefony/security` : `IWebAuthnCredential`,
 `IWebAuthnCredentialStore`, `IWebAuthnCredentialSummary`, `IWebAuthnListQuery`,
@@ -644,7 +642,7 @@ doit afficher « passkeys désactivées », pas un 503 (`SecurityAdminApi.ts:532
 backend sans comptage (Redis).
 
 Côté UI, l'écran **Profil** (`/nodefony/profile`) de Studio porte l'enrôlement self-service et l'écran de login le bouton
-passkey (`AuthStore.ts:209`).
+passkey (`AuthStore.loginWithPasskey()`, `AuthStore.ts:212`).
 
 ## 📜 Normes appliquées
 
@@ -658,7 +656,7 @@ passkey (`AuthStore.ts:209`).
 | Clé publique COSE                   | RFC 8152 / RFC 9052                | `IWebAuthnCredential.publicKey` (`IWebAuthnCredential.ts:16`)      |
 | FIDO2 / CTAP2                       | plafond `maxCredentialCountInList` | `passkeys.maxPerUser` (`config.ts:515`)                            |
 | Assurance d'authentification        | NIST SP 800-63B (AAL2)             | `passkeys.userVerification` (`config.ts:483`)                      |
-| Contrôle d'accès (IDOR)             | OWASP A01                          | `WebAuthnService.removeUserCredential()` (`webAuthn.ts:507`)       |
+| Contrôle d'accès (IDOR)             | OWASP A01                          | `WebAuthnService.removeUserCredential()` (`webAuthn.ts:502`)       |
 
 La conformité cryptographique fine (parsing CBOR, formats d'attestation, vérification des signatures
 ES256/RS256/EdDSA) est portée par `@simplewebauthn/server` — Nodefony fournit et prouve les
@@ -673,26 +671,25 @@ requête. Le code en tire trois conséquences.
   réel (`WebAuthnService.#ensureLib()`, `webAuthn.ts:545`) — une app qui n'enrôle personne ne paie
   jamais son coût de parse.
 - **Rien d'alloué quand c'est désactivé** : `passkeys.enabled: false` sort de `#build()` immédiatement
-  (`webAuthn.ts:129-131`) — pas de store, pas de `Map`.
+  (`webAuthn.ts:119-130`) — pas de store, pas de `Map`.
 - **Le listing admin ne matérialise jamais plus d'une page** : `listPage` applique les filtres au
   store (`IWebAuthnCredentialStore.ts:114`). Le seul appel non paginé, `findByUser`, est borné par
   `maxPerUser` — par conception (`IWebAuthnCredentialStore.ts:88`).
 
 ## ⚠️ Pièges (symptôme → cause → correction)
 
-| Symptôme                                             | Cause (dans le code)                                                       | Correction                                                     |
-| ---------------------------------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------- |
-| `409` à l'enrôlement                                 | Plafond `passkeys.maxPerUser` atteint (`webAuthn.ts:355`)                  | Retirer un appareil, ou relever `maxPerUser`                   |
-| `400 No challenge` au `verify`                       | Défi absent : déjà consommé, ou pas de cookie renvoyé                      | Un défi = un `verify` ; envoyer le cookie (`credentials`)      |
-| `401` systématique en production                     | Origine hors liste blanche, ou `rpId` ≠ domaine servi                      | Renseigner `passkeys.origins` + `rpId` enregistrable           |
-| Passkey KO en dev sur `127.0.0.1`                    | Une IP n'est pas un `rpId` valide → repli `localhost`                      | Accéder par `https://localhost:<port>`                         |
-| Passkeys d'un sous-domaine inutilisables sur l'autre | `rpId` unique, résolu au boot, pas de résolution par `Host`                | Choisir un `rpId` parent commun (`example.com`)                |
-| Login refusé après restauration d'une sauvegarde     | `signCount` régressif → clone suspecté (§6.1.1)                            | Comportement voulu — ré-enrôler l'appareil                     |
-| Tout le monde verrouillé dehors après un déploiement | `store` resté en `memory` : credentials volatils (`webAuthn.ts:183`)       | Déclarer une infra durable ; le `WARNING` boot le disait       |
-| `503 WebAuthn unavailable`                           | `passkeys.enabled: false` ou boot du service échoué                        | Activer `passkeys` ; vérifier le store configuré               |
-| Un anonyme distingue les comptes à passkey           | `allowCredentials` peuplé vs vide sur `login/options`                      | Ne pas envoyer `username` (usernameless) ; rate-limit la route |
-| `total` absent du listing admin                      | Backend curseur (Redis) → `countCredentials()` rend `-1`                   | Paginer par `nextCursor`, ne pas afficher de total             |
-| Passkeys orphelines après renommage d'un compte      | `userId` = `me.username` figé à l'enrôlement (`WebAuthnController.ts:109`) | Ne pas renommer, ou ré-enrôler après renommage                 |
+| Symptôme                                             | Cause (dans le code)                                                       | Correction                                                |
+| ---------------------------------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------- |
+| `409` à l'enrôlement                                 | Plafond `passkeys.maxPerUser` atteint (`webAuthn.ts:355`)                  | Retirer un appareil, ou relever `maxPerUser`              |
+| `400 No challenge` au `verify`                       | Défi absent : déjà consommé, ou pas de cookie renvoyé                      | Un défi = un `verify` ; envoyer le cookie (`credentials`) |
+| `401` systématique en production                     | Origine hors liste blanche, ou `rpId` ≠ domaine servi                      | Renseigner `passkeys.origins` + `rpId` enregistrable      |
+| Passkey KO en dev sur `127.0.0.1`                    | Une IP n'est pas un `rpId` valide → repli `localhost`                      | Accéder par `https://localhost:<port>`                    |
+| Passkeys d'un sous-domaine inutilisables sur l'autre | `rpId` unique, résolu au boot, pas de résolution par `Host`                | Choisir un `rpId` parent commun (`example.com`)           |
+| Login refusé après restauration d'une sauvegarde     | `signCount` régressif → clone suspecté (§6.1.1)                            | Comportement voulu — ré-enrôler l'appareil                |
+| Tout le monde verrouillé dehors après un déploiement | `store` resté en `memory` : credentials volatils (`webAuthn.ts:183`)       | Déclarer une infra durable ; le `WARNING` boot le disait  |
+| `503 WebAuthn unavailable`                           | `passkeys.enabled: false` ou boot du service échoué                        | Activer `passkeys` ; vérifier le store configuré          |
+| `total` absent du listing admin                      | Backend curseur (Redis) → `countCredentials()` rend `-1`                   | Paginer par `nextCursor`, ne pas afficher de total        |
+| Passkeys orphelines après renommage d'un compte      | `userId` = `me.username` figé à l'enrôlement (`WebAuthnController.ts:109`) | Ne pas renommer, ou ré-enrôler après renommage            |
 
 ## 🧪 Tests & couverture
 

package/docs/webhooks.md

@@ -66,11 +66,11 @@ Le détail de chaque étape est plus bas, dans **Architecture interne**.
 
 Trois usages courants, tous branchés sur des événements que Nodefony émet déjà :
 
-| Ce que tu veux                                                             | Tu abonnes                           | Le tiers qui reçoit                |
-| -------------------------------------------------------------------------- | ------------------------------------ | ---------------------------------- |
-| Être prévenu quand quelqu'un s'acharne sur un compte                       | `login.failure`                      | un canal Slack, un SMS d'astreinte |
-| Garder une trace inviolable des accès, hors de l'application               | `*`                                  | un SIEM, un bucket d'archives      |
-| Couper l'accès d'un salarié partout ailleurs quand sa session est révoquée | `token.revoked`, `session.destroyed` | ton annuaire, ton outil de tickets |
+| Ce que tu veux                                                             | Tu abonnes                                | Le tiers qui reçoit                |
+| -------------------------------------------------------------------------- | ----------------------------------------- | ---------------------------------- |
+| Être prévenu quand quelqu'un s'acharne sur un compte                       | `login.failure`                           | un canal Slack, un SMS d'astreinte |
+| Garder une trace inviolable des accès, hors de l'application               | `*`                                       | un SIEM, un bucket d'archives      |
+| Couper l'accès d'un salarié partout ailleurs quand sa session est révoquée | `session.revoked`, `token.reuse_detected` | ton annuaire, ton outil de tickets |
 
 Le premier, en entier — un serveur qui prévient une équipe quand un compte est attaqué :
 
@@ -251,7 +251,7 @@ import { Buffer } from "node:buffer";
 // prettier-ignore
 import { Controller, controller, Post, Body, Headers, BypassFirewall } from "@nodefony/framework";
 
-const SECRET = (process.env.NODEFONY_HOOK_SECRET ?? "").replace(/^whsec_/, "");
+const SECRET = (process.env.NF_HOOK_SECRET ?? "").replace(/^whsec_/, "");
 
 @controller("/hooks")
 class HookMiniController extends Controller {
@@ -308,7 +308,7 @@ import { Buffer } from "node:buffer";
 import { Controller, controller, Post, Body, Headers, BypassFirewall } from "@nodefony/framework";
 
 /** Secret `whsec_…` donné par l'émetteur — via l'environnement, jamais en dur. */
-const SECRET = process.env.NODEFONY_HOOK_SECRET ?? "";
+const SECRET = process.env.NF_HOOK_SECRET ?? "";
 /** Fenêtre anti-rejeu (s) : un message plus vieux est refusé. */
 const TOLERANCE_S = 300;
 
@@ -418,8 +418,8 @@ Les catégories d'audit disponibles (`AuditCategory`, `IAuditEvent.ts:24`) donne
 | ---------- | -------------------------------------------------------------------------- |
 | `auth`     | Login/logout, chaîne d'authentification (`login.success`, `login.failure`) |
 | `authz`    | Accès accordé/refusé, voters, `@IsGranted` (`access.denied`)               |
-| `token`    | Jetons longue durée émis/révoqués — JWT refresh, PAT (`token.revoked`)     |
-| `session`  | Cycle de vie de session (`session.opened`)                                 |
+| `token`    | Jetons longue durée et clés d'API (`token.issued`, `apikey.revoked`)       |
+| `session`  | Cycle de vie de session (`logout`, `session.revoked`)                      |
 | `oauth`    | Login social : authorize, callback, provisioning JIT                       |
 | `webauthn` | Passkeys : enregistrement, assertion                                       |
 | `csrf`     | Défense CSRF déclenchée                                                    |
@@ -672,7 +672,7 @@ abandon. Chaque retry **repasse par la file bornée** (`#scheduleRetry()`,
 
 ### Auto-désactivation d'un endpoint mort
 
-Chaque issue finale passe par `WebhookService.markDelivery()` (`webhooks.ts:687`) : succès →
+Chaque issue finale passe par `WebhookService.markDelivery()` (`webhooks.ts:682`) : succès →
 `failureCount = 0` ; échec → incrément. Au-delà de `autoDisableThreshold` (défaut **20**), l'endpoint
 est **désactivé** et un unique événement d'audit `webhook.disabled` est émis — **un par endpoint qui
 meurt**, jamais un par échec (le volume resterait ingérable). Mettre le seuil à `0` désactive
@@ -725,7 +725,7 @@ Section `webhooks` du schéma Zod (`webhooksSchema`, `security/nodefony/config/c
 
 > [!NOTE]
 > `timestampToleranceS` est **transporté** dans la politique de livraison
-> (`getDeliveryPolicy()`, `webhooks.ts:667`) mais l'émetteur ne l'applique jamais : la fenêtre
+> (`getDeliveryPolicy()`, `webhooks.ts:663`) mais l'émetteur ne l'applique jamais : la fenêtre
 > anti-rejeu est par nature un contrôle du **récepteur**. Traite cette valeur comme la tolérance que
 > tu documentes à tes destinataires — c'est celle du récepteur qui protège.
 
@@ -956,21 +956,21 @@ secret, et sait **simuler des pannes** pour observer retries et auto-désactivat
 
 ## ⚠️ Pièges (symptôme → cause → correction)
 
-| Symptôme                                                | Cause (dans le code)                                                                                            | Correction                                                                   |
-| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
-| Boot : « webhooks désactivés » en production            | Aucune `encryptionKey` — fail-safe (`webhooks.ts:299`)                                                          | `npx nodefony security:secrets` puis câbler `NF_WEBHOOK_KEY`                 |
-| Après redémarrage, les signatures ne valident plus      | Clé **éphémère** de dev : les secrets stockés sont illisibles                                                   | Poser une `encryptionKey` stable ; tourner les secrets des endpoints         |
-| `422` à la création d'un endpoint                       | `assertPublicUrl()` refuse la cible (IP interne, schéma, userinfo)                                              | Viser une URL publique en `https://` ; en dev, `denyPrivateIps: false`       |
-| Rien n'arrive alors que l'endpoint est actif            | Aucun `auditService` → dispatcher inactif (`webhooks.ts:191`)                                                   | Vérifier que l'audit est activé ; le CRUD seul ne livre rien                 |
-| Un événement « métier » n'arrive jamais                 | La source est le **journal d'audit**, pas un bus applicatif                                                     | S'abonner à une action d'audit existante                                     |
-| Signature invalide côté récepteur                       | Corps re-sérialisé avant le HMAC, ou en-tête `webhook-id`/`-timestamp` ignoré                                   | Lire le corps **brut** ; signer `{id}.{timestamp}.{body}`                    |
-| 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:565`)                                                  | 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                  |
-| 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 que depuis un pod | Le snapshot n'est chargé qu'au boot (`webhooks.ts:325`) ; les pods qui n'ont pas vu l'écriture gardent l'ancien | Redémarrage tournant après une mutation, ou router l'admin sur tous les pods |
+| Symptôme                                                                       | Cause (dans le code)                                                                                       | Correction                                                             |
+| ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
+| Boot : « webhooks désactivés » en production                                   | Aucune `encryptionKey` — fail-safe (`webhooks.ts:299`)                                                     | `npx nodefony security:secrets` puis câbler `NF_WEBHOOK_KEY`           |
+| Après redémarrage, les signatures ne valident plus                             | Clé **éphémère** de dev : les secrets stockés sont illisibles                                              | Poser une `encryptionKey` stable ; tourner les secrets des endpoints   |
+| `422` à la création d'un endpoint                                              | `assertPublicUrl()` refuse la cible (IP interne, schéma, userinfo)                                         | Viser une URL publique en `https://` ; en dev, `denyPrivateIps: false` |
+| Rien n'arrive alors que l'endpoint est actif                                   | Aucun `auditService` → dispatcher inactif (`webhooks.ts:191`)                                              | Vérifier que l'audit est activé ; le CRUD seul ne livre rien           |
+| Un événement « métier » n'arrive jamais                                        | La source est le **journal d'audit**, pas un bus applicatif                                                | S'abonner à une action d'audit existante                               |
+| Signature invalide côté récepteur                                              | Corps re-sérialisé avant le HMAC, ou en-tête `webhook-id`/`-timestamp` ignoré                              | Lire le corps **brut** ; signer `{id}.{timestamp}.{body}`              |
+| 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:565`)                                             | 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            |
+| 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:406`), pas immédiatement | Attendre au plus `snapshotTtlS`, ou le baisser                         |
 
 ## 🧪 Tests & couverture
 
@@ -983,7 +983,7 @@ depuis vitest, jamais figés ici :
   historique, bornes de perf, arrêt) ; `webhookSignature` (vecteur officiel Standard Webhooks,
   altération du corps/id/timestamp) ; `webhookDelivery` (pin d'IP, non-suivi des 3xx, timeout,
   politique de protocole, capture du corps de réponse) ; `webhookStore` (CRUD mémoire + copie
-  défensive) ; `webhookAdminApi` (les 8 endpoints, rôles, `400`/`404`/`422`/`503`, audit des
+  défensive) ; `webhookAdminApi` (les 9 endpoints, rôles, `400`/`404`/`422`/`503`, audit des
   mutations) ; `webhookPagination` (harnais du banc de contrat sur le store mémoire).
 - **attaque (red-team)** — `webhookSsrf.attack.test.ts` : matrice threat-first dérivée d'OWASP SSRF
   et de CAPEC-664 (IPv4-mapped IPv6 sous 7 notations, confusion `userinfo`, IP encodée
@@ -1017,6 +1017,3 @@ Couverture : `npm run coverage` dans `@nodefony/security`. Revue de sécurité d
 - La **source des événements** livrés → [audit](audit.md) · Le pare-feu qui les produit → [firewall](firewall.md)
 - Secrets et jetons du module, mêmes principes de chiffrement au repos → [tokens](tokens.md)
 - Vocabulaire transverse de la sécurité → [lexique](lexique.md)
-</content>
-
-</invoke>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nodefony/security",
-  "version": "10.0.0-alpha.9",
+  "version": "10.0.0-beta.2",
   "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",
@@ -48,28 +48,28 @@
     "directory": "src/packages/@nodefony/security"
   },
   "dependencies": {
-    "@simplewebauthn/server": "14.0.2",
+    "@simplewebauthn/server": "14.0.3",
     "jose": "6.2.12",
     "tslib": "2.8.1",
     "zod": "^4.6.5"
   },
   "devDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.9",
-    "@nodefony/http": "^10.0.0-alpha.9",
-    "@nodefony/user": "^10.0.0-alpha.9",
-    "@types/node": "26.6.2",
-    "@vitest/coverage-v8": "5.0.1",
-    "nodefony": "^10.0.0-alpha.9",
-    "vitest": "5.0.1"
+    "@nodefony/framework": "^10.0.0-beta.2",
+    "@nodefony/http": "^10.0.0-beta.2",
+    "@nodefony/user": "^10.0.0-beta.2",
+    "@types/node": "26.6.3",
+    "@vitest/coverage-v8": "5.0.3",
+    "nodefony": "^10.0.0-beta.2",
+    "vitest": "5.0.3"
   },
   "license": "Apache-2.0",
   "readmeFilename": "README.md",
   "contributors": [],
   "peerDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.9",
-    "@nodefony/http": "^10.0.0-alpha.9",
-    "@nodefony/user": "^10.0.0-alpha.9",
-    "nodefony": "^10.0.0-alpha.9"
+    "@nodefony/framework": "^10.0.0-beta.2",
+    "@nodefony/http": "^10.0.0-beta.2",
+    "@nodefony/user": "^10.0.0-beta.2",
+    "nodefony": "^10.0.0-beta.2"
   },
   "files": [
     "dist",