WebAuthn / passkeys — MFA résistant au phishing (FIDO2)

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

Une passkey remplace le mot de passe par une paire de clés dont la privée ne quitte jamais l’authenticator (Touch ID, Windows Hello, clé FIDO). Le serveur ne détient que des clés publiques et ne fait que vérifier des signatures : rien à hameçonner, rien à rejouer, rien à voler dans la base. Nodefony orchestre les deux cérémonies FIDO2 dans WebAuthnService (^{webAuthn.ts:92}) et fournit les endpoints BFF prêts à l’emploi — tu n’écris que l’appel navigateur.

📍 Documentation › Sécurité › WebAuthn / Passkeys

🧠 Le modèle mental — deux cérémonies, un défi jamais rejoué#

Une passkey ne se transmet pas : elle signe un défi. Le serveur émet un aléa, l’authenticator le signe, le serveur vérifie la signature contre la clé publique qu’il a stockée. Deux cérémonies, la même mécanique.

Le défi vit hors du service, en session BFF, posé par le controller (WebAuthnController.registerOptions(), ^{WebAuthnController.ts:100}). 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.

📖 Lexique#

Qu’est-ce qu’une passkey — et quelles failles elle ferme#

Un mot de passe est un secret partagé : il se tape, donc il se hameçonne ; il se stocke, donc il fuit ; il se rejoue. Une passkey supprime le secret partagé — il n’y a plus rien à donner à un faux site.

Quatre failles fermées par construction :

1. Hameçonnage — la signature est liée à l’origine et au rpId. Un faux domaine ne peut pas obtenir de signature valide : le navigateur refuse de la produire.
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}).
4. Clonage d’authenticator — le signCount doit croître ; une régression signale une copie (IWebAuthnCredential.signCount, ^{IWebAuthnCredential.ts:22}).

C’est le facteur d’authentification le plus fort disponible aujourd’hui (NIST AAL2, AAL3 avec une clé matérielle attestée).

La vision Nodefony — le serveur ne détient aucun secret#

WebAuthnService (^{webAuthn.ts:92}) orchestre, il ne fait pas de cryptographie : le parsing CBOR/COSE et la vérification des signatures (ES256/RS256/EdDSA) sont délégués à @simplewebauthn/server, une bibliothèque auditée de l’écosystème, importée paresseusement au premier usage (WebAuthnService.#ensureLib(), ^{webAuthn.ts:540}) — l’enrôlement et le login sont des chemins froids, ils ne doivent rien coûter aux requêtes ordinaires.

Trois partis pris assumés :

• Le service est sans état de session. Le défi est porté par le controller BFF ; le service reçoit toujours l’expectedChallenge en paramètre (WebAuthnService.verifyRegistration(), ^{webAuthn.ts:317}). Conséquence pratique : le service se teste sans transport, et un défi n’est jamais « oublié » quelque part côté serveur.
• 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 unique, messages uniformes, anti-IDOR).

🚀 Démarrage rapide#

1. Les passkeys sont déjà actives — la config utile#

passkeys.enabled vaut true par défaut (^{config.ts:1106}). Ce que tu déclares vraiment, c’est ton domaine : sans rpId, le service prend le domaine de l’app, et bascule sur localhost si c’est une adresse IP (un navigateur refuse une IP comme rpId, ^{webAuthn.ts:134}).

// nodefony.config.ts (extrait) — activer les passkeys pour TON domaine
import { defineConfig, use } from "nodefony";

export default defineConfig(() => ({
  modules: [
    use("@nodefony/security", {
      passkeys: {
        // Le domaine auquel les passkeys seront LIÉES. Domaine enregistrable
        // ou "localhost" — jamais une IP, jamais un domaine avec port.
        rpId: "app.example.com",
        rpName: "Ma boutique",
        // Liste blanche des origines acceptées (prod) : sans elle, seule
        // l'origine dont le hostname == rpId est tolérée.
        origins: ["https://app.example.com"],
        // Exiger la biométrie/PIN, pas la simple présence → AAL2.
        userVerification: "required",
        // "any" = le navigateur peut aussi proposer un téléphone par QR.
        authenticatorAttachment: "any",
        maxPerUser: 10,
      },
    }),
    "@nodefony/framework",
  ],
}));

2. Les endpoints BFF sont FOURNIS#

Dès que @nodefony/security est chargé, le framework monte six routes (mountWebAuthnRoutes(), ^{WebAuthnController.ts:308}) :

❗ Important

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 la zone protégée (security.webauthn.credentials.list, ^{WebAuthnController.ts:314}).

3. Ce que TU écris : l’appel navigateur#

Seule la moitié cliente te revient. startRegistration() / startAuthentication() de @simplewebauthn/browser encapsulent navigator.credentials.create() / .get() et la conversion base64url des options JSON.

// src/passkeys.ts (navigateur) — l'appel qui déclenche Touch ID / Windows Hello
import {
  startAuthentication,
  startRegistration,
  type PublicKeyCredentialCreationOptionsJSON,
  type PublicKeyCredentialRequestOptionsJSON,
} from "@simplewebauthn/browser";

const BASE = "/nodefony/security/api/webauthn";

async function postJson<T>(path: string, body: unknown): Promise<T> {
  const res = await fetch(`${BASE}${path}`, {
    method: "POST",
    headers: { "content-type": "application/json" },
    // Le cookie de session porte le DÉFI entre `options` et `verify`.
    credentials: "same-origin",
    body: JSON.stringify(body),
  });
  if (!res.ok) throw new Error(`${path} → ${res.status}`);
  return (await res.json()) as T;
}

/** Enrôler : l'utilisateur est DÉJÀ connecté (session BFF ouverte). */
export async function enrollPasskey(): Promise<string> {
  const optionsJSON = await postJson<PublicKeyCredentialCreationOptionsJSON>(
    "/register/options",
    {},
  );
  // La paire est créée DANS l'authenticator ; la privée n'en sort jamais.
  const attestation = await startRegistration({ optionsJSON });
  const out = await postJson<{ verified: boolean; credentialId: string }>(
    "/register/verify",
    { response: attestation },
  );
  return out.credentialId;
}

/** Se connecter sans mot de passe. `username` omis = passkey découvrable. */
export async function loginWithPasskey(
  username?: string,
): Promise<{ username: string }> {
  const optionsJSON = await postJson<PublicKeyCredentialRequestOptionsJSON>(
    "/login/options",
    username ? { username } : {},
  );
  const assertion = await startAuthentication({ optionsJSON });
  const out = await postJson<{ verified: boolean; user: { username: string } }>(
    "/login/verify",
    { response: assertion },
  );
  return out.user; // la session BFF est ouverte : le cookie est posé
}

Référence vivante dans le dépôt : Studio fait exactement ces deux appels — AuthService.loginWithPasskey() (^{AuthService.ts:108}) et AuthService.registerPasskey() (^{AuthService.ts:130}).

4. Ce qu’on observe#

WA=https://localhost:5152/nodefony/security/api/webauthn

# 1) Enrôler sans session → 401 (register exige d'être connecté)
curl -sk -o /dev/null -w '%{http_code}\n' -X POST $WA/register/options   # 401

# 2) Défi de login en anonyme → 200 + un cookie de session qui PORTE le défi
curl -sk -i -X POST -H 'Content-Type: application/json' -d '{}' $WA/login/options
# HTTP/2 200 … set-cookie: … ; {"challenge":"…","rpId":"localhost","timeout":60000, …}

# 3) Rejouer ce cookie sur un verify bidon → 401 (défi trouvé, crypto KO),
#    puis 400 au 2e essai : le défi a été CONSOMMÉ.

🏗️ Architecture interne — les deux cérémonies, pas à pas#

Enrôler une passkey sur un compte existant#

WebAuthnService.generateRegistrationOptions() (^{webAuthn.ts:276}) construit le défi et les contraintes. excludeCredentials y liste les passkeys déjà enrôlées (^{webAuthn.ts:291}) : le même authenticator ne peut pas s’inscrire deux fois. Dans authenticatorSelection (^{webAuthn.ts:261}), authenticatorAttachment n’est transmis que s’il vaut autre chose que "any" — "any" rend la main au navigateur, téléphone par QR compris.

WebAuthnService.verifyRegistration() (^{webAuthn.ts:317}) enchaîne dans cet ordre :

1. Vérification déléguée à verifyRegistrationResponse — défi, origine, rpIdHash, flags, attestation (^{webAuthn.ts:330}). Tout échec devient un message uniforme WebAuthn registration failed (^{webAuthn.ts:305}).
2. Plafond d’enrôlement — countByUser, refus 409 si maxPerUser est atteint (^{webAuthn.ts:313}). Volontairement après la cryptographie et avant le save : un client peut poster register/verify sans jamais appeler register/options — c’est l’écriture qu’il faut garder, pas la génération du défi.
3. Persistance de la clé publique + l’état initial (^{webAuthn.ts:359}) — backupEligible dérive de credentialDeviceType === "multiDevice" (^{webAuthn.ts:359}).

Se connecter sans mot de passe#

WebAuthnService.generateAuthenticationOptions() a deux régimes : sans userId, allowCredentials est omis et l’authenticator propose ses passkeys découvrables — l’expérience « usernameless » ; avec userId, la liste est calculée depuis findByUser pour cibler un porteur précis.

C’est le controller qui choisit le régime, et il ne se fie jamais à la requête : WebAuthnController.loginOptions() cible depuis l’identité de la session quand il y en a une (ré-authentification), et sert un défi découvrable sinon. Le username que poste un client anonyme est ignoré.

❗ Important

Un allowCredentials peuplé pour un anonyme dit deux choses de trop : que ce compte porte une passkey, et lesquelles. W3C WebAuthn L3 (« Privacy leak via credential IDs ») rappelle qu’un credentialId est un identifiant corrélable : exposé, il permet de dés-anonymiser un utilisateur d’un site à l’autre et de confirmer une hypothèse d’identité avec un accès momentané à son authenticator. Les deux remèdes de la spec sont ceux appliqués ici : credentials découvrables, ou authentification préalable. Conséquence de configuration : passkeys.residentKey: "discouraged" produit des credentials non découvrables — leurs porteurs ne pourront plus se connecter, et le service l’avertit au boot.

WebAuthnService.verifyAuthentication() (^{webAuthn.ts:415}) résout le credential par son id (^{webAuthn.ts:415}), vérifie la signature contre la clé publique stockée, puis applique l’état : signCount, backupState, uvInitialized (jamais rétrogradé), lastUsedAt (^{webAuthn.ts:455}). Le controller ouvre alors la session BFF avec authFlow.establishSessionFor() (^{WebAuthnController.ts:64}).

❗ Important

La détection de clone est ici, pas dans le store. La monotonie du signCount est vérifiée pendant la cérémonie ; le store, lui, écrit ce qu’on lui donne — une régression 5→1 y passe sans broncher, et c’est prouvé exprès (cas A3 de webauthn.attack.test.ts). Un store n’est pas un arbitre de sécurité.

Perdre son téléphone — révoquer une passkey#

Deux chemins, deux portées :

• Self-service : DELETE …/webauthn/credentials/{id} → WebAuthnService.removeUserCredential() (^{webAuthn.ts:461}). La suppression n’aboutit que si le credential appartient au demandeur (^{webAuthn.ts:467}) ; 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} (^{SecurityAdminApi.ts:560}) — audité, et 404 identique si la passkey n’appartient pas à l’utilisateur visé, même pour un admin.

Une passkey non sauvegardée (backupState: false) meurt avec son appareil — d’où le filtre backedUp du listing admin (IWebAuthnListQuery, ^{IWebAuthnCredentialStore.ts:47}), qui liste exactement les porteurs à risque de verrouillage.

⚙️ Configuration#

Table dérivée du schéma Zod passkeysSchema (^{config.ts:447}), monté sous la clé passkeys (^{config.ts:1106}).

Mise en situation — trois politiques, trois publics#

Situation 1 — grand public, zéro friction (le défaut). Tes utilisateurs sont sur leur téléphone ou leur portable : une empreinte suffit, et la passkey se synchronise (iCloud, Google) pour qu’un changement d’appareil ne les enferme pas dehors. Rien à écrire, ce sont les défauts — l’OS propose Touch ID / Windows Hello sans QR (authenticatorAttachment: "platform") et les passkeys arrivent avec backupEligible: true.

Situation 2 — comptes sensibles, clé matérielle imposée. Administrateurs, production : tu veux une clé physique séparée et la certitude d’une vérification humaine.

passkeys: {
  authenticatorAttachment: "cross-platform", // YubiKey & co, pas la biométrie du portable
  userVerification: "required",              // PIN/biométrie obligatoire → AAL2
  attestation: "direct",                     // demande le certificat fabricant
  maxPerUser: 5,
},

⚠️ Attention

attestation: "direct" récupère le certificat, il ne le valide pas : Nodefony ne vérifie ni l’AAGUID ni la chaîne contre la MDS FIDO (^{config.ts:487}). Tant que cette vérification n’est pas faite dans ton application, tu as la donnée, pas la garantie AAL3 — et tu paies un coût de vie privée (l’attestation identifie le modèle d’authenticator).

Situation 3 — login sans identifiant (usernameless). Tu veux un bouton « Se connecter » unique, 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.

🛡️ rpId et origines — l’ancre anti-phishing#

Le rpId est ce à quoi la passkey est soudée. Le navigateur refuse de signer pour un autre domaine : c’est ce lien, et pas une vérification côté serveur, qui rend l’hameçonnage impossible.

Résolution au boot (WebAuthnService.#build(), ^{webAuthn.ts:113}) : passkeys.rpId sinon le domaine de l’app ; une adresse IP ou une adresse IPv6 bascule sur localhost (^{webAuthn.ts:134}), seul host non-domaine que la spécification autorise. En développement, accède donc au serveur par https://localhost:5152, jamais par 127.0.0.1.

L’origine attendue est calculée par WebAuthnService.#expectedOrigin() (^{webAuthn.ts:523}) en trois temps : la liste blanche passkeys.origins si elle est non vide (^{webAuthn.ts:484}, la voie de production) ; sinon l’origine de la requête, mais seulement si son hostname est exactement le rpId (^{webAuthn.ts:134} — en dev, localhost:5173 et localhost:5152 passent tous deux, le port est ignoré, sans jamais ouvrir à un domaine tiers) ; en dernier recours https://{rpId} (^{webAuthn.ts:537}).

⚠️ Attention

Un seul rpId par instance. Il est résolu une fois au boot et stocké dans le service ; il n’y a aucune résolution par en-tête Host. Un déploiement multi-domaine (a.example.com et b.example.com) doit choisir un rpId parent commun (example.com) — sinon les passkeys enrôlées sur l’un ne fonctionneront pas sur l’autre.

🔐 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:146}). 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.

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:394}). 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}).

Ce qui borne donc cette lecture, c’est passkeys.maxPerUser (défaut 20, ^{config.ts:509}) :

• le refus est un 409 porté par WebAuthnError (^{WebAuthnError.ts:15}), rendu tel quel au client parce qu’il est authentifié — rien à énumérer, et il doit comprendre qu’il faut retirer un appareil (^{WebAuthnController.ts:264}) ;
• le comptage est natif (countByUser, ^{IWebAuthnCredentialStore.ts:97}) : COUNT / SCARD, jamais un findByUser().length — webAuthnEnrollmentLimit.test.ts le prouve avec un store espion (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#

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.

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

⚠️ Attention

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.

Les autres gardes de cette surface, toutes couvertes par des tests d’attaque :

Entité de persistance — ce qui est écrit, et en quels types#

Un credential (IWebAuthnCredential, ^{IWebAuthnCredential.ts:10}) ne contient aucun secret : la clé privée n’existe que dans l’authenticator.

Spécification SQL : ^{webAuthnCredentialEntity.ts:28}, index sur userId (^{drizzle/nodefony/entity/webAuthnCredentialEntity.ts:54}). Schéma documentaire : ^{mongoose/nodefony/entity/webAuthnCredentialEntity.ts:25} — _id est le credentialId (String, pas un ObjectId), les horodatages sont des Number epoch ms.

Trois constats de conception : aucun TTL ni gc — une passkey est permanente jusqu’à révocation explicite, IWebAuthnCredentialStore n’a pas de maintenance (^{IWebAuthnCredentialStore.ts:75}) ; nickname est stocké et rendu, jamais écrit par le framework — aucune API publique ne le renseigne, le champ existe pour une UX « renommer cet appareil » côté application ; userId est l’identifiant applicatif (me.username, figé à l’enrôlement, ^{WebAuthnController.ts:109}) — renommer un compte orphelinise donc ses passkeys.

🧩 Backends de stockage — quatre enregistrés, et comment brancher le tien#

Le contrat IWebAuthnCredentialStore (^{IWebAuthnCredentialStore.ts:75}) est résolu au boot (^{webAuthn.ts:141}) : un adapter déjà posé au container gagne, sinon la fabrique nommée par passkeys.store est appelée via le registre (registerWebAuthnStore(), ^{webAuthnCredentialStoreRegistry.ts:30}).

store: "auto" (défaut) suit l’infra déclarée, borné aux backends réellement enregistrés (^{webAuthn.ts:155}) — la décision (configuré → résolu, raison) est publiée au kernel et visible dans Studio (^{webAuthn.ts:195}). Deux garde-fous de production :

• un store explicitement configuré mais inconnu avorte le boot en production (^{webAuthn.ts:176}) — jamais de repli silencieux vers un store volatil ;
• memory en production déclenche un WARNING qui nomme l’impact : passkeys perdues au redémarrage, utilisateurs verrouillés hors de leur compte (^{webAuthn.ts:183}).

Les backends, en détail#

Brancher son propre store#

Une fabrique suffit — le cœur n’apprend jamais le nom d’un backend :

import { registerWebAuthnStore } from "@nodefony/security";
import type { IWebAuthnCredentialStore } from "@nodefony/security";

registerWebAuthnStore("mon-backend", ({ container, config }) => {
  // Implémenter IWebAuthnCredentialStore : findById / findByUser / countByUser /
  // save / update / delete / listPage / countCredentials.
  return new MyWebAuthnStore(container, config) as IWebAuthnCredentialStore;
});

Puis passkeys: { store: "mon-backend" }. Ton implémentation doit passer le banc de contrat (webauthnPaginationContract.ts) : il vérifie la borne limit, l’ordre, les filtres, et surtout que la vue admin ne porte jamais la clé publique.

🧰 API publique#

Le point d’entrée est le service webauthn du container ; les signatures vivent dans le graphe symbolique (.ai/symbols.json).

Types publics ré-exportés par @nodefony/security : IWebAuthnCredential, IWebAuthnCredentialStore, IWebAuthnCredentialSummary, IWebAuthnListQuery, MemoryWebAuthnCredentialStore, registerWebAuthnStore.

💡 Astuce

listUserCredentials() et listCredentialsPage() ne se remplacent pas. Le premier sert la fiche d’un porteur (borné par maxPerUser) et le login ; le second est le chemin froid d’une console d’administration, qui ne matérialise jamais plus d’une page et dont la projection exclut la clé publique par construction (IWebAuthnCredentialSummary, ^{IWebAuthnCredentialStore.ts:16}).

📡 Observabilité — Studio#

Le data plane admin du module expose trois routes (^{SecurityAdminApi.ts:301}), toutes en ROLE_NODEFONY_ADMIN :

<!-- prettier-ignore -->

Deux comportements à connaître : la redaction est par construction — la vue admin omet la clé publique et le userId déjà présent dans le chemin (toCredentialView(), ^{SecurityAdminApi.ts:267}), et ce n’est pas un masquage tardif, le contrat de store ne la produit jamais ; la lecture est défensive — passkeys désactivées → { enabled: false, items: [] } et non une erreur, la console doit afficher « passkeys désactivées », pas un 503 (^{SecurityAdminApi.ts:501}). total: -1 signale un 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}).

📜 Normes appliquées#

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 invariants qui l’entourent.

⚡ Performance & mémoire#

Les cérémonies sont un chemin froid : quelques appels par utilisateur et par appareil, jamais par requête. Le code en tire trois conséquences.

• Import paresseux de la bibliothèque : @simplewebauthn/server n’est chargé qu’au premier usage réel (WebAuthnService.#ensureLib(), ^{webAuthn.ts:540}) — 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:122}) — 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)#

🧪 Tests & couverture#

Cinq familles couvrent la brique — les chiffres exacts vivent dans la carte de l’aperçu (régénérée par gen-counters.mjs, jamais figée ici) :

• unit — webAuthnCredentialStore (matrice fonctionnelle), webAuthnCredentialOwnership (anti-IDOR), webAuthnEnrollmentLimit (le plafond : refus, tenue au-delà du seuil, portée par utilisateur, libération d’une place, comptage natif), webauthnPagination ;
• intégration — webauthn-bff (serveur réel : Zero Trust sur register, persistance du défi, authenticatorAttachment renvoyé) + les bancs de store drizzle / mongoose / redis ;
• e2e (base réelle) — webauthn-store-postgres.e2e et webauthn-store-mysql.e2e, gatés par l’infra : sans variables de base ils se skippent, et un skip compte comme vert ;
• bancs de contrat — webauthnPaginationContract : les invariants du listing tenus par tous les backends, en deux capacités (offset et cursor), dont la projection sans clé publique ;
• attaque — webauthn.attack au niveau store (A1 anti-takeover par update, A2 isolation findByUser, A3 le store n’arbitre pas l’anti-clone, A4 collision d’index) et webauthn-attack au niveau câblage (E1/E1bis rejeu de défi, E2 confusion de cérémonie, E3 anti-énumération, E4 message uniforme).

Ce qui manque : aucun test de charge ni de mémoire dédié — cohérent avec un chemin froid, mais un pic d’enrôlement n’est pas caractérisé. La cryptographie n’est pas re-testée ici : elle est déléguée à une bibliothèque auditée, et les tests doublent volontairement cette dépendance pour n’éprouver que la politique Nodefony.

Skills utiles : nodefony-security-review (mode red/blue-team), nodefony-load-test pour caractériser un pic d’enrôlement. Couverture : npm run coverage dans @nodefony/security.

🔗 Pour aller plus loin#

• ⬆️ Retour au hub : Sécurité — vue d’ensemble · Toute la documentation

• 🧭 Pages sœurs : Authenticators · totp

• Autre second facteur → totp · Mot de passe et autres preuves → authenticators

• Le firewall qui protège tes routes une fois la session ouverte → firewall

• La session BFF qui porte le défi → session

• Identité fédérée (Google, GitHub…) → oauth2

• Vue d’ensemble du module → index