Strict Origin and RP ID Cryptographic Binding for WebAuthn Conditional UI

--- description: Strict Origin and RP ID Cryptographic Binding for WebAuthn Conditional UI - Enforces strict canonical Origin and Relying Party Identifier (RP ID) validation during passkey authentication, specifically under WebAuthn Conditional UI (autofill) flows. Mandates that server-side ceremony verifiers evaluate cryptographically bound client data against hardcoded or strictly allowlisted canonical origins rather than dynamic Host/Origin HTTP request headers, mitigating reverse-proxy interception and MitM credential harvesting. globs: src/auth/**/*.{ts,js}, src/api/auth/**/*.{ts,js}, src/server/auth/**/*.{ts,js}, src/controllers/auth/**/*.{ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/webauthn-conditional-ui-rpid-binding-guardrail" --- # Strict Origin and RP ID Cryptographic Binding for WebAuthn Conditional UI > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Trusting Dynamic Client Request Headers for WebAuthn Origin and RP ID Verification ## System Constraints You are a Principal Security Architect enforcing FIDO2/WebAuthn Level 3 specifications. Your task is to mandate strict, immutable Relying Party (RP ID) and Origin verification during passkey autofill (Conditional UI) assertion validation. Prohibit any reliance on untrusted or dynamic HTTP headers (such as Host, X-Forwarded-Host, or Origin) when verifying collectedClientData and authenticatorData. ## Strict Guidelines - Engineers MUST ALWAYS validate clientDataJSON.origin and authenticatorData.rpIdHash against immutable, cryptographically expected values sourced from server-side trusted configuration, never from runtime client HTTP headers. - Engineers MUST NOT accept dynamic Host or Origin headers (e.g., req.headers.host, req.headers.origin, req.get('host')) as the expected RP ID or expected Origin parameters in verifyAuthenticationResponse. - Services MUST enforce that the RP ID is a valid registrable domain suffix of the canonical origin, matching exact production domains (e.g., 'auth.example.com' must assert rpId 'example.com' or 'auth.example.com'). - Services MUST verify the clientDataJSON.type parameter strictly equals 'webauthn.get' for authentication assertions before parsing credential signatures. - Components NEVER permit conditional UI autofill ceremonies to bypass signature verification, user verification checks, or replay counter validation under the assumption that browser mediation guarantees channel integrity. ## Bad vs Good Implementations ### Vulnerable Dynamic Header Origin Matching vs Canonical Whitelist Verification #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Deriving expectedOrigin and expectedRPID from the incoming request headers (Host or Origin) allows an adversary operating an automated reverse-proxy (e.g., Evilginx/Modlishka) to satisfy server-side validation using the adversary's domain, completely bypassing the origin isolation protections of WebAuthn. ```typescript import { verifyAuthenticationResponse } from '@simplewebauthn/server'; import { Request, Response } from 'express'; export async function handleConditionalLogin(req: Request, res: Response) { const { assertionResponse, challenge } = req.body; // DANGEROUS: Deriving expectedOrigin and expectedRPID dynamically from incoming client headers. // An attacker routing traffic through a reverse-proxy (e.g., evil-proxy.com) will have // this dynamic origin passed directly into validation, allowing stolen assertion validation. const dynamicOrigin = `${req.protocol}://${req.get('host')}`; const dynamicRPID = req.hostname; const verification = await verifyAuthenticationResponse({ response: assertionResponse, expectedChallenge: challenge, expectedOrigin: dynamicOrigin, expectedRPID: dynamicRPID, authenticator: { credentialID: assertionResponse.id, credentialPublicKey: Buffer.from(req.session.publicKey, 'base64'), counter: req.session.counter, }, }); if (verification.verified) { return res.json({ success: true }); } return res.status(401).json({ error: 'Authentication failed' }); } ``` #### Production Standard (Correct) > **Standard**: Expected origins and RP IDs are bound to immutable, hardcoded server configurations. The verification rejects assertions targeting spoofed reverse proxies, properly checks user verification flags, and increments counter stores to thwart replay attacks. ```typescript import { verifyAuthenticationResponse } from '@simplewebauthn/server'; import { Request, Response } from 'express'; // HARDENED: Canonical, immutable relying party definitions sourced strictly from validated server configuration const CANONICAL_ORIGINS = Object.freeze([ 'https://auth.example.com', 'https://login.example.com', ]); const CANONICAL_RP_ID = 'example.com'; export async function handleConditionalLogin(req: Request, res: Response) { const { assertionResponse } = req.body; const sessionChallenge = req.session.currentChallenge; if (!sessionChallenge) { return res.status(400).json({ error: 'Missing active challenge session' }); } try { // Origin is verified against a strict compile-time or config-bound allowlist, // completely immune to Host-header poisoning or reverse-proxy rewriting attacks. const verification = await verifyAuthenticationResponse({ response: assertionResponse, expectedChallenge: sessionChallenge, expectedOrigin: CANONICAL_ORIGINS, expectedRPID: CANONICAL_RP_ID, authenticator: { credentialID: assertionResponse.id, credentialPublicKey: Buffer.from(req.session.publicKey, 'base64'), counter: req.session.counter, }, requireUserVerification: true, }); if (!verification.verified) { return res.status(401).json({ error: 'Cryptographic assertion rejected' }); } // Rotate challenge and update counter to prevent replay attacks delete req.session.currentChallenge; req.session.counter = verification.authenticationInfo.newCounter; return res.json({ success: true }); } catch (error) { return res.status(401).json({ error: 'Authentication signature validation failed' }); } } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Strict Origin and RP ID Cryptographic Binding for WebAuthn Conditional UI

Strict Origin and RP ID Cryptographic Binding for WebAuthn Conditional UI defines an industrial-grade behavioral standard for security engineering. Enforces strict canonical Origin and Relying Party Identifier (RP ID) validation during passkey authentication, specifically under WebAuthn Conditional UI (autofill) flows. Mandates that server-side ceremony verifiers evaluate cryptographically bound client data against hardcoded or strictly allowlisted canonical origins rather than dynamic Host/Origin HTTP request headers, mitigating reverse-proxy interception and MitM credential harvesting. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Trusting Dynamic Client Request Headers for WebAuthn Origin and RP ID Verification Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Trusting Dynamic Client Request Headers for WebAuthn Origin and RP ID Verification	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS validate clientDataJSON.origin and authenticatorData.rpIdHash against immutable, cryptographically expected values sourced from server-side trusted configuration, never from runtime client HTTP headers.

Engineers MUST ALWAYS validate clientDataJSON.origin and authenticatorData.rpIdHash against immutable, cryptographically expected values sourced from server-side trusted configuration, never from runtime client HTTP headers.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.